# TCPShield [TCPShield](https://tcpshield.com) is a DDoS Mitigation provider focusing on the security, stability, and uptime of websites and gameservers. Our goal is to improve the lives of our users by making their experience running online services a safe and enjoyable one. ### How it Works TCPShield is a distributed proxy. That means we intercept packets on your behalf, and then run our special algorithms to determine the legitimacy of incoming traffic to your service. When TCPShield detects invalid or malicious traffic, we mitigate it and keep your services online. ### Anycast network & performance We take the latency and performance of our network very seriously. Interested in latency metrics? We've got you covered. Check our latest results [here](https://www.hyperspin.com/en/quicktest.php?action=result\&qtid=1526397\&r=8610). ### First Steps At the moment, we specialize in providing DDoS Mitigation for Minecraft servers. To receive our premium mitigation, you can sign up for [our panel](https://panel.tcpshield.com) and visit our [onboarding documentation](/panel/panel-configuration) for more information on how to get your server up and running in under 15 minutes! # FAQ This is the FAQ for Miscellaneous answers to questions we often receive. ## Can you protect things other than Minecraft? In the past we have promised our customer that a general DDoS mitigation solution is on the way. And as of April 2025, the promise has been fulfilled: we currently support **ALL APPLICATIONS AND GAMES** using our newest [Sentry Tunnel](/vxlan/sentry-tunnel-features). That said, we still offer specialized support for **Minecraft**, including both [**Java Edition**](/panel/panel-configuration) and [**Bedrock**](/premium-features/geyser). Both can be routed through a single **CNAME record** for simplicity. Please note: [**Bedrock support is available only on the Premium plan**,](/premium-features/geyser) while **Java Edition** is supported on all plans. ## What are the limitations of TCPShield? How much capacity do you have? Our layer 4 capacity sits at 16 Tbps, and layer 7 up to an unlimited amount of connections per second. ## How much does TCPShield cost? TCPShield offers a free tier for anyone to use. We also have premium plans that give all kinds of goodies and increased limits which will scale to the largest of minecraft servers. You can read more about our plans [here](https://panel.tcpshield.com/billing/plans). ## Some person is using my assets on your network. Can you remove them from your service? No. We only respond to court orders & other legal take down requests. ## Can you have all my traffic routed to XYZ? Maybe, but doing so would jeopardize your ability to benefit from globally distributed network and the resiliency that comes with it. Unless you really understand the implications of requesting this, it's best not to. ## Where are TCPShield proxies located? We currently have frontend proxies located in: * Los Angeles, US * New York, US * Seattle, US * Dallas, US * Ashburn, US * Amsterdam, NL * London, UK * Frankfurt, DE * Tokyo, JP * Singapore, SG * Seoul, KR * Sydney, AU Available on paid plans (inquire for more details): * Warsaw, PL * Paris, FR * Miami, US ## Do you have any latency tests? Absolutely! Check our latest results here on Hyperspin: {% embed url="" %} # Commonly asked questions For general information and FAQ ### **1. What is proxy protocol? Why should I use it over TCPShield plugin?** The plugin is a more secure version of Proxy Protocol v2, which forwards client connection info like IP addresses through proxies—crucial for Minecraft servers using TCPShield, as otherwise all connections appear from TCPShield’s IPs. Unlike the standard Proxy Protocol, which is vulnerable to spoofing, this plugin uses a flag (`only-allow-proxy-connections`) to ensure only verified TCPShield proxies can connect via a secure handshake, blocking direct backend access and adding protection against MOTD scans. \ However, the plugin may conflict with other security plugins (e.g., antiVPN, antiBot or some Bungeecord forks), so disabling the flag is possible if needed—though not recommended. Importantly, TCPShield’s DDoS protection remains active even without the plugin. ***Q: If the plugin is not compatible with my setup, what should I use?*** Since February 2022, our service now supports proxy protocol v2 from our proxies to your backend, which means we can forward players’ IP addresses straight to you. Your server will no longer need the TCPShield plugin to extract the player’s IP Address, and this protocol is supported natively by Paper, Velocity, Bungeecord and other proxy servers. To take advantage of this feature, simply follow these steps: * Remove TCPShield plugin * Enable `proxy-protocol` (or `haproxy-protocol` if you are using Velocity) in your server's config. * Enable `proxy-protocol` in your backend set on the TCPShield Web panel (picture below). * **For customers with eligible TCPShield** [**Bedrock**](/premium-features/geyser) **setup:** Set `haproxy-protocol` to `true` in your Geyser config (Under `bedrock` and `java` section respectively). ![Proxy Protocol toggle can be found on your backend set](/files/rYtPkar2CYRwsgtlhjDI) Note: This approach does not validate connections are coming from us as the plugin did with hostname signatures, therefore it is imperative that you have a firewall to only accept inbound connections from us. ***Q: If I use the plugin and set the flag to “false”, should I use keep using the plugin?*** 1\. Even with the `only-allow-proxy-connections` set to false, our plugin still transports connection information, in this case being player’s IP Addresses. Without our plugin (or `proxy-protocol`), the IP Address of players joining your server would be coming from us. 2\. Setting the flag to `false` doesn’t mean your DDoS mitigation capacity will be lost: You will still be protected behind our network. The handshake between our proxies and your backend won’t perform, so that’s an extra layer of security lost, but you can setup your own firewall (`ufw`, `iptables` etc) to achieve a greater effect. ### 2. Why do I see random bedrock servers when I query in the bedrock client? By default, bedrock does not operate on hostnames. Due to the default DNS resolution behavior of Java CNAMEs, and the unfortunate limited availability of IPv4 addresses, you will sometimes have a case where a Java CNAME might resolve to an IPv4 where a bedrock server exists on the returned IP. This is normal, and can be fixed in one of two ways (**for customers using Premium plan or higher**): 1. If you have a Bedrock tunnel (created under the Bedrock section), you can safely use this DNS record for both Java + Bedrock concurrently. The result is much higher convenience for your users, since they can use the same subdomain across both platforms. 2. If you are unable to create a Bedrock CNAME, open a [ticket](https://discord.gg/tcpshield) and ask to be moved to an IP without a tunnel. This is a very simple request for us to carry out. ### 3. I’ve setup TCPShield correctly, yet my domain doesn’t work. Once you've made changes to your DNS records, there is a period called “DNS propagation” where your record needs time to update. That process can take a few minutes or up to a few hours depending on multiple factors (such as your ISP, how far away you are from the Root server, the Top-level domain servers, and the Authoritative nameserver). \ \ You can try forcing an update on your local DNS resolver by running the following (Windows): ``` ipconfig /flushdns ipconfig /release ipconfig /renew ``` or updating your [DNS server](https://support.perimeter81.com/docs/change-your-pc-dns-settings) to either 1.1.1.1/1.0.0.1 (Cloudflare resolver) or 8.8.8.8/8.8.4.4 (Google's)
{% hint style="info" %} **Reminder: TCPShield DOES NOT control the speed of the DNS propagation process.** {% endhint %} ### 4. How DNS propagation works: When a DNS record for `mydomain.com` updates, and try to access the newly updated `mydomain.com`, your computer will make a query to the Resolver server asking: “What is the IP Address corresponding to this domain?”. The Resolver server in this case is your ISP – Internet Service Provider (Comcast, AT\&T, Vodafone, etc.). \ \ Once your ISP receives the query, it will check its own cache memory. If it can’t find the specified domain, it will send a query to a root server – which is the top of the DNS hierarchy. If the information can’t be found within the root server, it will forward the request to a TLD (Top-level domain server), which stores address information for top level domains such as `.com`, `.net`, `.org`. \ \ If the TLD server still can’t resolve the query, it will make a last redirect of your request to an Authoritative Nameserver. The Authoritative Nameserver knows everything about the domain, and will respond to your Resolver server accordingly, and that information will get sent back to your computer. ### 5. Why do I see `<127.0.0.1 initial handler has pinged>` in the console? That's because we periodically request and cache your MOTD to stop SLP floods. What SLP floods do is repeatedly request your MOTD, forcing your server to respond and send a lot of outbound/egress traffic in the process. SLPs are very asymmetric bandwidth-wise so they're a very easy attack vector to throttle your egress bandwidth. \ \ To combat this, our proxies **fetch and store** your MOTD every second, so most requests get a **cached** instead of hitting your actual server. This means your server isn’t constantly spammed with requests, saving bandwidth. Since the MOTD is stored on the proxy’s system, when it does need to refresh the cache, it **grabs the MOTD internally** from itself, making it appear as if the request comes from `127.0.0.1`. ### 6. Why do I see Switzerland/Canada/Barbados... when checking the location of TCPShield proxies? \ We understand that GeoIP tools like nameMC may show Switzerland as our location, but we have to to clarify that this is a result of IP address registration, not the actual locations of our datacenters. Key insights: * Our network strategically spans Europe, North America, and Asia, ensuring that customers are always directed to the nearest proxies for optimal latency. * GeoIP tools associate us with Switzerland due to our IP addresses being registered there, but this isn't indicative of our physical proxies locations. * Customers are always routed to the closest proxies relative to their backend server, which will provides optimal latency. Another example that can help you understand this better: the IP address 8.8.8.8 is reachable globally, but when you look up Cloudflare, you will see that their location is California/USA. However the search doesn't dictate the multitude of their global data centers. To see which locations we have on our network, please refer to our [FAQ](/faq) section. \
# Features What does TCPShield do for you? ### Overview TCPShield uses proprietary mitigation strategies to give server owners the peace of mind in knowing their networks are safeguarded from attacks. All of these features aim to protect your server from a variety of denial of service attacks at every layer in the network stack. ### Layer 4 Mitigation In it's simplest form, TCPShield protects you from network-layer TCP and UDP floods. Common things like SYN floods, as well as UDP based reflection / amplification floods are immediately blocked at our edge. TCPShield is an anycasted network, meaning we stop attacks as close to the source as possible. ### Layer 7 Mitigation The main goal of attackers is to consume resources of your network to where it grinds to a halt. There are some of these attack vectors that can be found directly in the Minecraft protocol itself. Without giving out specifics, we preform checks against incoming Minecraft clients to ensure they behave like a real Minecraft player and not an attacker. This includes things like ping attacks, encryption attacks, and large amounts of server joins. ### Backend Protection / Hiding your IP The TCPShield plugin hides your IP address your BungeeCord/Spigot is running on by ensuring all connections incoming are authorized from the TCPShield network. At any given moment, thousands of devices are scanning the internet looking for open ports and logging information about it. Such systems can expose the backend IP address in order to directly attack your network, circumventing TCPShield as a whole. In addition, our plugin actively protects you from other known protocol vulnerabilities which have yet to be patched by many Spigot versions. ### Load Balancing As TCPShield accepts incoming connections to your server, players can be equally distributed to any number of backend servers. In other words, you can run multiple BungeeCord instances without the need for HAProxy and simply rely on TCPShield to do this for you. Simply insert multiple IP's for a single domain and TCPShield takes care of the rest, making it easier than ever to scale your network to meet demands. To see what type of load balancing we offer, go to this [link](https://docs.tcpshield.com/panel/panel-configuration#step-3.1-optional-advanced-settings-for-your-backend-set). # Contact There are many ways to contact TCPShield for support. The easiest way to contact us is to use [Discord](https://discord.gg/tcpshield). We also offer the ability to chat with us on [Telegram](https://t.me/sferg). If all else fails, you can [email ](mailto:admin@tcpshield.com)us as well. If you need to get in touch with a specific member of our team: * Steven Ferguson: [Telegram ](https://t.me/sferg)| [Twitter](https://twitter.com/szferguson) | [Email](mailto:steven@tcpshield.com) * Adrian Tran: [Email](mailto:adrian@tcpshield.com) * Ethan Richert: [Email](mailto:ethan@tcpshield.com) # Billing A quick overview of how billing works with TCPShield ### What happens if I go over my allocated bandwidth limit? When 90% of bandwidth has been used, we will email you every few hours to notify you that you are close to the bandwidth limit. At 100% utilization, your servers MOTD will be overwritten indicating how to resolve the issue. At this point players can still join, but MOTD will show that your resource limit has been reached. At 200% utilization or 5 days after you first reached 100%, your domains will be disabled and players will no longer be able to join through TCPShield.\ \ Bandwidth is calculated via ingress from your server and players to our network. We report the raw bytes we see, so you can keep track on your end as well of your own usage using applications like nload and iftop with 1-1 accuracy. ### What payment methods are accepted? PayPal and Debit/Credit Card are accepted payment methods. ### "I really need X feature and not X feature, can we modify the price of the plans?" No. We only make changes to limits on the plans for individuals on the enterprise plan. ### Activation It may take a few moments for your plan to activate after payment. If you have any issues, please feel free to reach out to TCPShield Staff any time. # Setup Process How to setup TCPShield on your Minecraft Network The process for setting up TCPShield is rather straightforward. The process generally takes 15 minutes for those who are experienced with DNS and basic system administration techniques. If you are not familiar with DNS, following the general steps and copying our examples should be enough to get your server protected. However, we know this can be a confusing process, and we would be happy to [assist ](/contact)you at any step of the way. \ \ If you would like to get setup with TCPShield, head over to our[ panel configuration](/panel/panel-configuration) page to begin the process of configuring TCPShield for your server. We also provide videos for a quick start using TCPShield. Every step documented in our configuration docs have a corresponding video. {% embed url="" %} You can review the rest of the playlist [here](https://www.youtube.com/watch?v=pq84gTsmpEQ\&list=PL3B7olIHt22M1ES_L91Op_cUwcLsW4aTe\&index=1). ## **Community videos** We also have another set of videos created by our community. If you have a video, please let us know and we will add it to this page! {% embed url="" %} {% embed url="" %} # Panel Configuration Configuring TCPShield for your network ## Before You Begin Some individuals may find it easier to follow a [our video series](https://www.youtube.com/watch?v=pq84gTsmpEQ\&list=PL3B7olIHt22M1ES_L91Op_cUwcLsW4aTe\&index=1\&ab_channel=StevenF) we have created for configuring TCPShield. This guide will explain with more detail, but for simple configurations our series will cover most cases. {% embed url="" %} If you are having trouble with the setup process, please make sure to read through our Setup Checklist or use our [Debug Tool ](https://debug.tcpshield.com/)to determine the issue. If all else fails, you reach out to us [here](https://discord.gg/QvRSdhHnGE). ## Step 1: Signup for TCPShield The first step for using TCPShield is signing up for [our panel](https://panel.tcpshield.com). After you have registered, you will be greeted with our home page. ![](/files/-MWXWkZm2gnLYYzUYnay) ## Step 2: Create a Network A "network" is the idea of a single Minecraft network. This could be as simple as a vanilla survival spigot server, or a 2000 player network multiple BungeeCord instances. A network can be named anything you'd like, this tutorial will be using CrunchyPVP as our fake minecraft server. ![](/files/-MWXWq__gfsZYZCxMcX1) ## Step 3: Adding Backends In TCPShield terminology, a backend is considered something TCPShield routes traffic too. For example, this could be a singular Spigot server, a BungeeCord instance, or a perhaps even multiple BungeeCords. \ Here, we need to add the IP's of our network we are trying to connect to TCPShield. First, navigate to the[ backend sets](https://panel.tcpshield.com/networks/backends) page and click "Add Set." ![](/files/-MWXWwCTOlRbgbOtMpLg) We can name the group of backends we are about to add as whatever we'd like. In my case, I'm going to call this "Production" because these are the backends we will be using in our live environment for my server. In the example of CrunchyPvP, I am running two BungeeCords I want to load balance between, so I'm going to add the IP/port combination for both of those instances (1.1.1.1:25565, 1.2.3.4:25565). ![](/files/-MWXX-2ojN0PDd_2AD27) Click save. Notice: I did not add anything related to my spigot servers here. ONLY the thing accepting the connection from the TCPShield network should be listed here. If you want to have just a single spigot instance, you would point directly to that. ## Step 3.1 (Optional): Advanced settings for your backend set When adding multiple servers behind the same backend set, you can choose suitable load balacing mode as follow: * **Least connection** (Default): Players are directed to the backend server with the fewest active connections. * **Random**: Players are assigned to a backend server at random. * **Latency**: Our latest addition—connections are now balanced based on latency, ensuring players join the server with the lowest available latency for the best experience.
**For customers using** [**Vulcan AC**](https://www.spigotmc.org/resources/vulcan-anti-cheat-advanced-cheat-detection-1-7-1-21-4.83626/): There's now an option in your backend that, when enabled, ensures your server is fully compatible with the plugin.

Choosing suitable load balancing mode if necessary

## Step 4: Add Domains First, navigate to the domains page and click "Add Domain". My domain is CrunchyPvP.net, which I will insert into the modal. I will then click the dropdown for the backend set and use the one we just created. ![](/files/-MWXX3iLU-l4qBJhWP1M) Badlion Proxy is an optional step that is specific for users of Badlion AntiCheat. This is not something required for most networks. \ Then, click "Begin verification" ## Step 5: Domain Verification Domain verification is the process we require for all domains on the TCPShield network. This confirms ownership of the domain using DNS and is required for security reasons. We recommend when you verify your domain, you use TXT records. ![](/files/-MWXX8beipkZeXGGBxsZ) For this step, I will copy the TXT record and insert it on the root(required) of my domain on Cloudflare DNS manager. ![](/files/-MWXXCOk8oKm4V-paZcr) Once my domain is saved, you can attempt to verify the domain on the TCPShield panel. This process can unfortunately can take sometimes up to several hours for DNS to fully propagate to where Cloudflare (our internal resolver) will see it. This is why we highly recommend everyone use Cloudflare for DNS management. This process often trips up many people, so before contacting TCPShield staff, we would encourage to double check that the TXT record has properly propagated worldwide using [https://www.whatsmydns.net](https://www.whatsmydns.net/). As a general note, from our observations Namecheap DNS takes the longest with an average time of 5 hours. ## Step 6: Point Domains and DNS Now that we have verified the domain with TCPShield, we need to decide how we want players to connect to our network. Often, owners want players to only join with a subdomain like `play.crunchypvp.net`. Other times, owners would like the ability for both players to join with `play.crunchypvp.net`or `crunchypvp.net` but still allow a website to exist with an A record. I want my server to allow people to join through CrunchyPvP.net, so I will set this accordingly in the hostname field on the domain page. TCPShield domains are wildcarded, so we do not need to add another record for `play.crunchypvp.net.` ![](/files/-MWXXJAig-9p120uNnXA) **From here, we will need to configure DNS to point to the TCPShield network. Please follow our** [**DNS guide**](/panel/dns-setup) **and return here once you have completed the setup process.** ## Step 7: Install the TCPShield Plugin On the domains page, you will be given downloads to the TCPShield plugin. This plugin must be installed while using TCPShield in order for players to have the correct IP addresses on your server. If you don't run these plugins, all players will look like they are originating from the same IP address. These plugins are open source, and are available for modification and pull requests [here](https://github.com/TCPShield/RealIP\\). *Note:* If you are running a BungeeCord server, you only need the Real IP plugin on your BungeeCord instances. \ \ *Note:* If you are running Lilypad (while not recommended), you will need to contact us for a way to get the correct IP addresses for your players. This is a limitation of Lilypad (No plugins), not TCPShield. You can learn more about the plugin, its configuration, and why its important [here](/panel/tcpshield-plugin). ## Alternative Step 7: Setup Proxy Protocol If your server might already have plugins that authenticate players (antiBot, antiVPN or authMe) - then our plugin might be incompatible. In that case, to properly forward your player's IP addresses, you can setup Proxy Protocol: * Make sure TCPShield plugin is **not** installed. * Enable `proxy_protocol` (or `haproxy-protocol` if you are using Velocity) in your server's config. For Paper (Standalone setup) this setting can be found in `paper-global.yml` * Enable `proxy-protocol` in your backend set on the TCPShield Web panel. * **For customers with eligible TCPShield** [**Bedrock**](/premium-features/geyser) **setup:** Set `enable-proxy-protocol` and `use-proxy-protocol` to `true` in your Geyser config (Under `Bedrock` and `Remote` section respectively). More information regarding Proxy Protocol can be found [here](https://docs.tcpshield.com/panel/pages/zPcw0psLWpTEYm0nnIGl#id-1.-differences-between-our-plugin-vs-proxy-protocol). It's recommended at this step to also firewall your backend to not accept connection except from TCPShield sources. Congratulations! 🎉\ \ You have officially joined the TCPShield Network! If something didn't work quite right, don't hesitate to contact us using the ticket system on our [discord](https://discord.gg/tcpshield). While you wait for help from our staff, we strongly encourage you triple check all the configuration steps we've made here. We also have a [checklist ](/troubleshooting/setup-checklist)that can assist you determining issues. # DNS Setup This guide will show you everything you need to get your network pointed to your protected CNAME. ### Step 1: Login to your DNS manager This guide will assume you are using **Cloudflare**. Login to Cloudflare, and select your desired domain from the home page. ![Click here after logging in](/files/-MWXXVzpZRdmaqS_5lUN) ### Step 2: Remove existing DNS records pointed to your backend Once you are on the DNS management page, visually check to see if you have any DNS records lying around that are currently pointed to your current backend. Let's assume in this example your backend is `192.168.0.1`. {% hint style="info" %} By "backend" we are referring to the actual IP address that TCPShield is forwarding traffic to. This is typically the IP address your Bungee instance is listening on. {% endhint %} In our makeshift example, we have the following two records that players currently use to connect. ![Click the "X" next to those records to remove them.](/files/-MWXX_fz2mA5of5kjJq-) ### Step 3: Point subdomains to your protected CNAME Now that we have removed the old subdomains, we are now ready to point our server to TCPShield. Click the "**Add record**" button at the top of the page (next to search) and you should be presented with something that looks like this. In this example we will be creating a DNS record for the "mc" and "play" subdomains. {% hint style="info" %} Your protected CNAME is found in the top right of the "Domains" page and is specifically made for you. {% endhint %} ![](/files/-MWXXdnJ8PbkCCdAWkUB) {% hint style="warning" %} If you get DNS validation error code 1004, there are still DNS records that exist which you have not removed yet. {% endhint %} After this step, you should be able to connect successfully to your server via TCPShield. To verify your DNS setup is correct, enter your domain name into and select "CNAME" and you should get your protected CNAME back. ### Aside: Allowing players to login without a subdomain If you want your players to login to your server without a subdomain, i.e. `examplepvp.com` ensure you have a wildcard record setup with us (this is typically default). Now, we will go through the process of creating an SRV record such that your players can login directly with your domain name. First, we need to create a subdomain that our SRV will point to. In this example, follow the steps above but set the name to "tcpshield" and the target to your protected CNAME as normal. Ensure proxy status is off when you create this record. You should have something that looks like this: ![This is the record our SRV will point to](/files/-MWXXiNJWruDuvDypW_U) Now, we will create an SRV record such that when players enter `examplepvp.com` in their client, it will redirect them to `tcpshield.examplepvp.com` seamlessly. This is fairly straight forward to do, and copying the example below will obtain the desired behavior. {% hint style="warning" %} Ensure you remove any other SRVs you may have on your root-level domain before you proceed to this step. {% endhint %}

Example of SRV record creation

After you fill out the necessary details, click **save**. You should then be able to login directly with your root-level domain on Minecraft without issues. If you cannot connect right away, give your DNS time to update. If you still cannot connect, there is likely an error with your current DNS configuration or you have stale SRV records lying around that are configured to your root-level domain. {% hint style="danger" %} Do not set the "target" on your SRV record to your protected TCPShield CNAME! You will get "Invalid host" in the client as a result. Also, the SRV port **MUST BE 25565!** The mapping to your port happens on our side, not on DNS side of things. {% endhint %} If you have any other issues or questions regarding to DNS setup, do not hesitate to reach out to our staff. Most DNS configuration issues are typically very trivial to diagnose and resolve. Before you reach out, we would like to encourage you to double check your configuration using [https://www.whatsmydns.net](https://www.whatsmydns.net/) to ensure that the DNS records have propagated to the world. # TCPShield Plugin Documentation regarding the TCPShield Plugin {% hint style="info" %} As of February 2022, we now support [**Proxy Protocol v2**](https://docs.tcpshield.com/panel/pages/zPcw0psLWpTEYm0nnIGl#1.-differences-between-our-plugin-vs-proxy-protocol). The TCPShield plugin is incompatible with this feature, as well as it's no longer a requirement for our service. Please check out this [page](https://docs.tcpshield.com/panel/pages/zPcw0psLWpTEYm0nnIGl#1.-differences-between-our-plugin-vs-proxy-protocol) for further details. {% endhint %} TCPShield requires our plugin installed to allow access to the TCPShield Network. The plugin should only be run on your "Frontend machines" such as your BungeeCord(s) or Spigot, but never both. Historically, this plugin was referred to as RealIP, but now we simply call it the TCPShield plugin. ### Configuration Our configuration is very simple, and often requires zero change on your part. \ \ `only-allow-proxy-connections` It is very important you keep the only-allow-proxy-connections to `true` when in production. If this isn't set to true, you are NOT protected by TCPShield and are vulnerable to scanners which can find your backend IP address. `timestamp-validation` Can be picked between available modes: * htpdate: uses a synchronized date * system: uses the system time * off: deactivates timestamp validation `enable-geyser-support` For your own safety it is **crucial** that you do only set this to `true` if you are using TCPShield's Geyser tunnel. If you do not follow our advice, your backend is not only easily scannable but your IP is easily queryable by DNS and thus prune to attacks. We do not provide support in case you do this anyways. `debug-mode` Can be turn on to true to gather useful information that can help diagnosing your issues `pre-login-event` This option can be toggle either true/false to fix Velocity pre-login issue `prefer-protocollib` This defaults to true so users with ProtocolLib will use that over the regular Paper integration, this is due to that implementation exposing MOTDs to direct connect users, this however does require version 5.x.x of ProtocolLib or it will throw an error, disable that config option if you're using Paper with an unsupported version of ProtocolLib. ### IP Whitelist: How to use this feature: 1. Create a file with a `.list` extension 2. Add each entry using a [CIDR](https://whatismyipaddress.com/cidr) format, separated by a new line. Example: ```python 128.24.55.1/32 54.44.33.22/27 ``` ### Supported Versions {% hint style="info" %} If you are running Spigot standalone (i.e. no proxy in front) you will need to install [ProtocolLib](https://ci.dmulloy2.net/job/ProtocolLib/) for the plugin to work {% endhint %} The plugin is a Bungee/Spigot hybrid. We have tested against the following versions: * BungeeCord 1.16.1 * Spigot 1.12.2 (Requires [ProtocolLib](https://ci.dmulloy2.net/job/ProtocolLib/)) * Paper 1.8.8 to 1.20.2 (Requires [ProtocolLib](https://ci.dmulloy2.net/job/ProtocolLib/)) * Velocity 1.20.2 * FlameCord 1.20.2 * Waterfall 1.20.2 * Many more! This does not mean your version of Bungee/Spigot won't work, we just cannot guarantee it at this time. If you find a version in which it doesn't work against, please contact our support. We also ensure the plugin will work on Java 8 and 11. We do have the ability to support LilyPad, however for many reasons we do NOT recommend you use it. If you need LilyPad support, please reach out to our staff. ### Plugin Conflicts There are some plugins we know of that conflict with the TCPShield plugin. This list is not exhaustive, but at this time the following plugins conflict. If you must use a plugin that is known to have conflicts with TCPShield, please refer to our section regarding [`proxy-protocol`](https://docs.tcpshield.com/panel/pages/zPcw0psLWpTEYm0nnIGl#1.-differences-between-our-plugin-vs-proxy-protocol). * ServerMOTDPlus * TBD Please consider reaching out to these authors and asking them to adjust the event priority of their plugins ### A General Debugging Tip If your server is having issues, and you suspect TCPShield may be the issue, you can disable the `only-allow-proxy-connections` option. You, or a player you trust can be then given the backend IP to directly connect to see if the problem persists. By doing this, you will bypass TCPShield and perhaps find it easier to find the root cause of the issue. However, do not do this for long periods of time. This is risky to leave disabled as a scanner could pickup your MOTD and DDoS your backend directly. ### Source Code The source code to our plugin can be found on [GitHub](https://github.com/TCPShield/RealIP). Pull requests are welcome! # Cloudflare Network TCPShield x Cloudflare Spectrum ## Summary As of November 2025 we have stand up the Cloudflare Network to bring additional mitigation capacity and serving as potential failover for our customers. This network leverage existing [Spectrum](https://www.cloudflare.com/application-services/products/cloudflare-spectrum/) massive Layer 4 global capacity, while providing our proprietary Layer 7 mitigation that greatly enhance your protection while maintaining the lowest possible latency overhead. To active the Cloudflare Network: Head to our panel -> go to Network -> Domain and on the bottom right corner you can toggle the Cloudflare Network. It's recommended to enable [proxy protocol](/panel/panel-configuration#alternative-step-7-setup-proxy-protocol) while using it. {% hint style="warning" %} * Customer need to have at least Pro Plan or higher to access this network. * This is a Minecraft only product. * Due to limited IP space, this network only support Java connections. Customers with Bedrock setup can still use our default network. To take advantage of both, you can setup an [SRV](/miscellaneous/protect-a-website) record. {% endhint %}
\ The pricing is as below:
PlanBandwidth Cost
Pro$12/TB
Premium$10/TB
Enterprise $0/TB (NO ADDITIONAL COST)
You can check the current bandwidth usage + charges on the Network Overview page, under Premium Bandwidth and Premium Charge:
# Geyser Information about using Geyser with TCPShield {% hint style="info" %} Bedrock support is a strictly Premium Plan only feature. To update, please go to our [plans](https://tcpshield.com/plans) page. {% endhint %} ## Setup ### Panel Setup First, create a **separate** backend set which points to your instance. {% hint style="info" %} To avoid lengthy debugging process, make sure you can login to your **IP:Port** on the Minecraft Bedrock client first i.e., please don't come to us with a broken Geyser instance. {% endhint %} ![An example for a Geyser backend set](/files/-MWXYV05amAysqUOMaVf) After you've created a backend set, you can head to the Bedrock section on our panel and create a Bedrock tunnel:

Creating Bedrock Tunnel

Select the backend set that you have created:

Select the appropriate backend set

Click 'Done,' and you will be able to create your Dedicated Bedrock CNAME. Here's what it does: * Since Minecraft: Bedrock edition does not support virtual hostname routing, we cannot offer a shared anycasted IP as we can with Java. To overcome this limitation, each IP must be provisioned statically per tunnel. * This IP address will efficiently redirect all traffic from Minecraft: Bedrock edition to the backend set you created above. Therefore, you don't need to attach a domain to this backend set on the TCPShield panel. You can now proceed to the next step: DNS Setup.

Copy your Bedrock CNAME and use it for the next step

{% hint style="danger" %} **Important**: while your Bedrock tunnel is active, you won't be able to delete the underlying backend set. If you want to change the your IP address later, you can simply click on **Edit**. Or you can Delete the tunnel and make another one again. {% endhint %} ### DNS Setup The DNS setup is quite similar to the setup one normally goes through to setup TCPShield. You need to point a new CNAME to the Bedrock CNAME target we've provided you. ![An example how to setup the CNAME](/files/-MWXYYZHxnC0eQijTgXe) #### Using the same domain to connect to both Geyser and Java Edition Because Bedrock CNAMEs use a special IP address which supports both Java and Bedrock traffic together, the same `example.bedrock.tcpshield.com` CNAME **can be used** **for both connection types**. Meaning, you can simply create a DNS record pointing only to this value for any subdomain, including root, and both will work together. **OPTIONAL: Setup a SRV record which points to your Java Edition server** The purpose of this section is if you as a customer want more control over the **providers** in which Java vs Bedrock traffic use. In the case you are using our Cloudflare network, this will be necessary to ensure Java traffic stays on Cloudflare. Say for for example, you would like to use `play.example.tld` to connect to both your Java Edition and Bedrock server. We can do that like below: {% hint style="warning" %} The CNAME for your Java Edition server has to be a different one than the one you want your players to connect to. In this case, we will use `tcpshield` as the name of the CNAME. {% endhint %} In order to get the SRV record setup, you can follow the guide [here](https://docs.tcpshield.com/panel/dns-setup#aside-allowing-players-to-login-without-a-subdomain). **Change the name of your Geyser CNAME** If you have already created the CNAME as described above, change its name to the subdomain you want your players to be able to connect to. If you haven't created the CNAME yet, you can follow the steps as outlined above with the difference to set your name to, in this example, `play`. ![An example of a full setup](/files/-MWXYa4GOTnlnxvQtbnV) ### Proxy Protocol Setup When using Geyser in combination with Java it's **highly recommended** that you switch to `proxy protocol`. Detailed instructions can be found [here](https://docs.tcpshield.com/premium-features/pages/zPcw0psLWpTEYm0nnIGl#1.-differences-between-our-plugin-vs-proxy-protocol). After this is done, you should be able to connect to both your Java Edition and Bedrock server with `play.example.tld`! ### Plugin Setup If you decide to use the plugin instead of proxy protocol, it should be noted the plugin does authorize incoming Geyser connections directly. Please create a new file under `plugins/TCPShield/ip-whitelist`. In this example, we will call this name `geyser.list`. Add these lines to the file: ``` 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 ``` After you have saved the newly-created file and restarted your server, the plugin has been setup. ### Firewall Setup If you are using proxy protocol or want to use improve the secure your backend: You should considered block all incoming connections using a firewall solution. For this example, `iptables` is used. ```bash ipset -F tcpshield ipset -X tcpshield ipset -N tcpshield nethash for IP in $(curl -q https://tcpshield.com/v4/); do ipset -A tcpshield $IP done iptables -t raw -F iptables -t raw -A PREROUTING -m set --match-set tcpshield src -p udp --dport 19132 -j ACCEPT iptables -t raw -A PREROUTING -p udp --dport 19132 -j DROP ``` ### Additional Setup: To avoid Geyser ratelimiting our IP addresses causing sudden disconnections / players unable to login, you should add this startup flag:\ `-DGeyser.RakRateLimitingDisabled=true` . Which will disable Geyser's IP ratelimit. # Premium Panel Features Detailing information of features available for customers under Premium plans or above ### 1. Mitigation settings Our Mitigation Settings panel allows you to configure advanced Layer 7 settings. Below, we guide you through each option to help you optimize your defensive measure.

Mitigation Settings: Configure Layer 7 Mitigation Settings to Enhance Security and Control Access

#### Connections Per Second Threshold Control the maximum number of connections per second your server should receive before TCPShield's L7 mitigation kicks in. * Slide the selector to set the threshold. * Typical settings range from 5 connections per second for small servers to higher numbers for servers with significant traffic. #### Ban Seconds In the event the threshold was breached, we issue a challenge to all incoming connection. This specifies the duration for which the an IP address will be banned across all our proxies, should it failed the challenge. * Input the total ban time in seconds. * Consider the nature of your traffic and the likelihood of false positives when setting the ban duration. #### Allow Seconds During layer 7 attacks we issue a challenge, the allow seconds is how long we should whitelist validated connections during the reconnect phase. * Set the duration in seconds that valid connections should be accepted after being validated. #### Mitigation message Customize the response message displayed after a user's connection is denied. * Enter your custom message in the text field. * Use clear, user-friendly language to inform users of their connection status. * Example:

Connection verified

#### VPN Blocking Prevent logins through VPNs, our system utilizes an extensive internal database sourced from multiple trusted databases. This feature is particularly valuable in countering individuals who attempt to circumvent IP bans or exploit VPN systems for malicious activities such as bot attacks:

Example of a successful block

You can also configure the kick message by the antiVPN, the textbox will appear when this feature is turn on. *** ### 2. Advanced Firewall TCPShield panel is equipped with 3 types of Advanced Firewall: IP Firewall, [ASN](https://en.wikipedia.org/wiki/Autonomous_system_\(Internet\)) Firewall and Country Firewall. {% hint style="info" %} User can choose to whitelist / blacklist certain entry depends on your defensive strategy {% endhint %}

Firewall Settings on TCPShield panel

1. **IP Firewall**: Takes an [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) block as an entry. Example: 51.145.11.12/30, 136.125.0.12/24 2. **ASN Firewall**: The user can utilize this firewall to deny / give access to certain network(s). Example usage: [90](https://bgp.he.net/AS90) (Oracle) or [20473](https://bgp.he.net/AS20473) (Vultr) 3. **Country Firewall**: Should be self-explanatory. *** ### 3. Attack History and Attack Notification The TCPShield notification system informs server admins of ongoing L7 attacks and their statuses.

Example of an attack

TCPShield allow the configuration to facilitate real-time notifications during DDoS attacks either through **email** or communication software such as Slack, Discord using **webhooks**. \ \ To take advantage of this feature, simply paste your webhook URL (can be generated on Discord within your channel) into the Callback URL box:

Adding call back URL

Once integrated, the result will look like this:

Example of attack notification working with Discord

*** ### 4. **Custom Cache Settings** Help you enhance your server's visibility with various settings: Offline MOTD, Display Unique Icons, and Personalize Offline Messages.

Caching feature on TCPShield panel

1. **Forward true server list ping**: Ensures the full subdomain is forwarded to your backend during MOTD queries. Useful for cases when wildcard domains are present and you do not wish to explicitly add each sub-domain. Benefits include allowing tracking of influencer domains, server lists, and trackers to assess per subdomain performance. 2. **Offline MOTD Enable**: Provide a custom MOTD to be returned when your backend server is unreachable/offline. 3. **Offline Kick Message**: Define a clear and informative message that players when logging to a offline server, informing your players of the offline status. 4. **Offline** [**Favicon**](https://www.google.com/search?client=firefox-b-d\&q=Favicon): User can upload a 64x64 image that players see in place of your server icon.

Offline Mode in action

*** ### 5. Network Analytic Our Network Analytics Dashboard provides comprehensive insights into the network performance and player engagement fo your servers. It displays metrics such as the bounce rate, unique visits, total bandwidth usage, player's client versions, player retention, and more. This document guides you through each section of the analytics dashboard. {% hint style="info" %} Currently our analytic can only retain 1 week of data. We are looking to extend the retention period in the future. {% endhint %}
#### Key Metrics: 1. **Bounce Rate**: Percentage of user that visit your server and don't come back. The lower = better 2. **Unique**: Total number of unique players 3. **Total Bandwidth**: The cumulative amount of bandwidth transferred to and from your server 4. **Attack Mitigated**: number of DDoS attacks (L7) that have been successfully mitigated 5. **Top Domains**: Lists the domains associated with your network and their traffic percentages 6. **Player Retention**: Shows the retention rate of new versus returning players over a week # Setup Checklist This guide is for when the setup for TCPShield is failing. This checklist will give you a list of things to double-check to ensure everything is configured correctly. 1. Is your domain verified? Is your domain pointing to the correct backend set? 2. Are you confident your backend server is accepting connections? Ensure the correct port that BungeeCord / Spigot is running on is open and matches what you have in the backend set on our panel. 3. Are you trying to join the backend IP directly? The TCPShield plugin (and proxy protocol) blocks this intentionally. 4. Have you configured the proxy protocol correctly? The TCPShield plugin and proxy protocol setting can't coexist. More information can be found [here](https://docs.tcpshield.com/commonly-asked-questions#1.-differences-between-our-plugin-vs-proxy-protocol). 5. Make sure you **do not** install the TCPShield plugin in both your proxy server and your game mode server. 6. If you are using TCPShield plugin, keep in mind that it might not be compatible with your existing plugins (antiBot and antiVPN specifically). Try disabling them or switch to [proxy protocol](https://docs.tcpshield.com/troubleshooting/pages/zPcw0psLWpTEYm0nnIGl#1.-differences-between-our-plugin-vs-proxy-protocol) instead. 7. Has your DNS [propagated](https://docs.tcpshield.com/troubleshooting/pages/zPcw0psLWpTEYm0nnIGl#3.-ive-setup-tcpshield-correctly-yet-my-domain-doesnt-work.)? It can take up to 24 hours sometimes for DNS to fully propagate for everyone. 1. Use to ensure this. 2. For more information on how DNS propagation works, please refer to [this](https://docs.tcpshield.com/troubleshooting/pages/zPcw0psLWpTEYm0nnIGl#3.-how-dns-propagation-works). 8. Have you tried using your subdomain instead of your SRV record? Some clients can have issues resolving your SRV record. 9. Does your backend set have the expected IP addresses in the panel? 10. Does your firewall accept connections from the TCPShield network? List [here](http://tcpshield.com/v4). The[ TCPShield Discord is available](https://discord.gg/tcpshield) if needed, but this should cover most issues people will encounter when setting up TCPShield. # Invalid Hostname If your server shows "Invalid hostname" in the server-list when attempting to query If your server shows "Invalid Hostname" when querying on the serverlist, this usually means you are accessing a domain (or IP) pointed to our network, but not actually registered within our database. ![Example of the error](/files/-MWXXtUUrT0-1spm51-R) ## Causes * You have a SRV record pointed directly to your `example.ipv4.tcpshield.com` CNAME * You are connecting directly to your CNAME (similar to SRV) * You have not registered and verified your domain with TCPShield * Your [root domain](https://world.siteground.com/kb/what-is-a-root-domain/)\* is not verified on our panel (usually behind an SRV record) * You have misspelled your domain name when entering it in the dashboard ## Fixes * If you have an SRV record, ensure it is going to a target that is registered on TCPShield (for example a subdomain that is already pointing to the protected CNAME) * Make sure you have your root domain is added and verified on the TCPShield web panel. * Ensure the domain you're attempting to reach is registered within your dashboard, with a reachable backend IP * If it is registered, ensure it is spelled properly * \*It's important to note that `domain.com` (your root domain) and `xxx.domain.com` (your subdomain) are two different types of domains. # Disconnected on Login If you login and are kicked with "Disconnected" immediately Upon login, if you receive "Disconnected" then your backend is most likely unreachable. ## Causes * Your server is not running on the IP and port specified on the panel * The IP and port on the panel is incorrect to what is defined on the panel * The IP address we are proxying to is non-routable from our network ## Troubleshooting Firstly, it is a good idea to determine if your server is reachable from the outside world. From a server that is not the one running your Bungee/Spigot, verify that it can actually connect to your server. We can do this using a tool call **netcat**. ## Installing netcat **Debian/Ubuntu** ``` apt-get install netcat -y ``` **CentOS/Fedora** ``` yum install netcat -y ``` ## Verifying connectivity Run the following command, with the IP and port replaced as necessary. ``` nc -v IP PORT -w 3 ``` If you see `25565 (?) open` in the output, then your server is listening on the port, but might be hanging and not accepting normal MC connections. If this is the case, remove the TCPShield plugin and ensure you can login to the raw IP and port from your client directly. If this works, check your dashboard to ensure your backend IP and port are correct. If you see `Connection refused` in the output, then our proxies can properly route to your backend IP, but your Minecraft server is not running on the defined port in your dashboard. Ensure these both match and/or update as necessary. Additionally, ensure your listening IP is correct in your `server.properties` if you are running Spigot, or `config.yml` if you are running Bungee. If you see `Connection timed out` in the output, then our proxies cannot properly route to your backend IP address. Check your server-sided firewall to ensure the backend port defined in your dashboard is open to the outside world. You may need to consult your hosting provider if modifying the server-side firewall does not work (for example, your IP address might not be bound properly to your machine). ## Finally If everything is configured properly, netcat should return the following output, and you should be able to login normally via the Minecraft client. ``` $ nc -v 51.161.99.10 25565 -w 3 ip10.ip-51-161-99.net [51.161.99.10] 25565 (?) open ``` # High Latency and General Lag If you are experiencing higher than normal server-sided latency ## Causes * Your server has higher than normal load average. Check `htop` to ensure no processes are consuming higher than normal CPU. * Your spigot instances themselves are suffering degraded TPS * The backend is located too far away from our edge proxies. (In other terms, your server is geographically too far from our edge network - as your internet packet has to travel a longer route to reach its destination. See our [FAQ](/faq) and [Premium Features](/premium-features/cloudflare-network) regarding locations). * There is packet loss between you and our network, which could result from: * Link saturation at any point in the route between us and you * The backend resides on an unstable network (i.e. residential) * Packets are taking a longer route on either the send or return path ## Troubleshooting We will use a tool called `mtr` to diagnose any packet loss that might be occuring between TCPShield and your backend. To get started, we will install the utility: **Debian/Ubuntu** ``` apt-get install mtr -y ``` **CentOS/Fedora** ``` yum install mtr -y ``` Now, we will perform an MTR to one of our proxies to determine packet loss on the return path from your server to TCPShield. We can do this as follows: ``` mtr 50.114.4.0 ``` You will see an output that looks something like this: {% hint style="info" %} The`???`on hop 5 is expected, as we have ICMP (ping packets) dropped across our network. {% endhint %} ``` Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. redacted 0.0% 29 0.6 0.7 0.5 1.3 0.0 2. ??? 3. be100-1007.nwk-5-a9.nj.us 0.0% 29 6.9 10.1 6.5 29.2 5.9 4. be100-1323.bhs-g2-nc5.qc.ca 0.0% 29 14.9 16.2 14.6 32.9 3.7 5. ??? ``` As you can see, this backend gets about 14ms to the edge network of BHS. There does not appear to be anything wrong in this trace. Here is an example of where something might be wrong: ``` Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. unassigned.psychz.net 0.0% 25 1.3 1.1 0.9 1.4 0.0 2. 10.22.23.1 0.0% 25 0.4 0.8 0.2 6.0 1.0 3. xe-2-0-8.r20.sydnau02.au.bb.gin.ntt.net 0.0% 25 0.5 12.1 0.4 104.7 22.4 4. ae-8.r22.lsanca07.us.bb.gin.ntt.net 85.3% 25 147.1 452.6 146.8 1623.3 262.9 5. ae-1.r00.lsanca07.us.bb.gin.ntt.net 0.0% 25 149.0 151.5 147.2 156.2 2.7 6. be3025.ccr41.lax04.atlas.cogentco.com 0.0% 24 148.5 151.8 146.3 180.7 6.7 7. be3360.ccr42.lax01.atlas.cogentco.com 0.0% 24 150.3 150.9 146.4 156.6 3.0 8. be3177.ccr22.sjc01.atlas.cogentco.com 0.0% 24 164.6 161.2 157.1 165.5 2.6 9. be3144.ccr41.sjc03.atlas.cogentco.com 0.0% 24 163.9 161.4 156.4 171.1 3.3 10. sjo-sv5-bb1-a9.ca.us 0.0% 24 163.5 161.3 156.7 166.1 2.9 11. be100-1368.pao-sv8-bb1-a9.ca.us 0.0% 24 157.2 161.3 157.2 166.7 2.5 12. chi-1-a9.il.us 0.0% 24 223.5 223.7 222.2 226.4 1.0 13. be100-1320.bhs-g1-nc5.qc.ca 0.0% 24 241.3 258.9 240.0 329.6 32.7 14. ??? ``` As you can see, we have high packet loss on hop 4 when packets leave Psychz's network in Australia to Los Angeles on NTT. In this case, you would need to contact your hosting provider and show them this MTR, as well as provide the IP you're testing from (your box IP), IP you're testing to (31.25.11.0), and other helpful related information that may help them diagnose. # How to Read a Traceroute This guide will teach you how to read a traceroute to identify potential connection issues or packet loss ## Gathering traceroutes To get a traceroute, open command prompt in Windows or Terminal on OSX and run the following. The first argument takes either a domain or IP address. ### Windows ``` tracert 1.2.3.4 ``` If you have issue with the command, download [WinMTR](https://winmtr.net/) is basically traceroute but with a visual interface for easier reading. ### Linux/OSX ``` traceroute 1.2.3.4 ``` {% hint style="info" %} Let the traceroute run for 1-2 minutes before assessing {% endhint %} ## Reading the traceroute Now that you have your traceroute, you will see something that looks like this. ``` traceroute to tcpshield.net (158.69.40.209), 64 hops max, 52 byte packets 1 10.13.95.1 (10.13.95.1) 302.809 ms 10.786 ms 182.727 ms 2 * * * 3 10.16.122.1 (10.16.122.1) 198.191 ms 33.049 ms 173.817 ms 4 10.16.122.4 (10.16.122.4) 1.832 ms 1.833 ms 1.752 ms 5 10.16.121.1 (10.16.121.1) 2.043 ms 1.957 ms 2.878 ms 6 10.59.226.21 (10.59.226.21) 1.965 ms 1.988 ms 1.919 ms 7 h84.gpvpn.redacted.com (x.x.x.x) 3.016 ms 2.810 ms 3.780 ms 8 h66-244-233-17.bigpipeinc.com (66.244.233.17) 6.295 ms 3.205 ms 3.110 ms 9 * * * 10 rc3so-be31-1.cg.shawcable.net (24.244.0.17) 4.217 ms 3.546 ms 3.533 ms 11 rc4ec-be13.il.shawcable.net (66.163.65.18) 33.704 ms 32.591 ms 37.759 ms 12 chi-5-a9.il.us (178.32.135.200) 32.540 ms 36.926 ms 34.108 ms 13 * * * 14 be7.bhs-vac1-a75.qc.ca (192.99.146.147) 416.777 ms 509.795 ms 432.394 ms 15 * * * 16 * * * ``` You will notice that by hop 14 we have 400ms+. Could this be TCPShield related? We will analyze this traceroute closely to see what might be causing this. Typical traceroutes are formatted like so: ``` (IP resolution) probe1, probe2, probe3 ``` Let's outline what each of these mean. | Label | Description | | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | hop # | Packets traverse the internet to their destination in a hop-by-hop basis. The hop number is simply a label identifying which sequence in that path your packets are currently traversing. | | hostname | The human readable representation of the current hop in the trace. Sometimes you may not get a hostname for every hop, and this is completely normal. It's on network operators to configure this if they choose to do so. | | IP | The numerical IPv4 address pertaining to the current hop. | | probe# | Each traceroute issues 3 ping (ICMP) requests to each of the hops being traversed. The number you see on each of the probes represents the round trip latency between your source machine and the target hop in milliseconds. | Traceroutes are read in-order starting from the first hop (at this point packets usually haven't exited the source network to the public internet yet), and the destination hop. Most hostnames you will see in a traceroute will contain information that may outline what location that router or switch is located, for example `ae7.cr7-chi1.ip4.gtt.net` indicates a router in Chicago belonging to GTT, `six-sea.netarch.akamai.com` is an endpoint in Seattle belonging to Akamai (located in SIX - Seattle Internet Exchange), and so on. {% hint style="info" %} Sometimes you may never reach the destination hop, like in the example above. This is completely normal for TCPShield, as we disable all protocols except TCP 25565/443/80 across our edge nodes. {% endhint %} Lets look at the above trace a bit more closely. ``` 1 10.13.95.1 (10.13.95.1) 302.809 ms 10.786 ms 182.727 ms 2 * * * 3 10.16.122.1 (10.16.122.1) 198.191 ms 33.049 ms 173.817 ms ``` The first 3 hops contain critical information here that will help us determine the cause for the high latency. You will see each of the 3 probes here have varying degrees of latency. Starting at the first hop, one of the probes has `302.809ms`. This definitely isn't expected as the first hop is usually your home router or switch in a residential network - something that should be below 5ms ideally for all probes on that hop. Indeed, we have 10ms shown on one of the probes, however the other 2 have latencies in the triple digits which signify an unstable connection. For context, I was running this traceroute over WiFi in an area with many connected clients. We can also see the same effects shown in the 3rd hop. During this point, our packets still have not left the internal network to the outside world yet - so as a result of our unstable connection to the WiFi router, this has introduced **propagation delay** to the remainder of the traceroute. As mentioned previously, packets are routed on the internet in a hop-by-hop basis. If one of the hops in that path experiences high latency or congestion, this will impact the quality of service for the remainder of the trace. In networking, a chain (or path in this case) is only as strong as its weakest link. {% hint style="info" %} Any hops where you see 10.0.0.0/8, 172.16.0.0/16, or 192.168.0.0/16 are RFC1918 addresses, which are reserved for internal networks. If you see IP addresses in these CIDRs, it usually signifies packets have not exited to the public internet yet. Any high latency within these hops typically propagate to the remainder of the trace. {% endhint %} This now gives us more clues as to what is happening at hop 14 - the last hop we could observe before hitting TCPShield's edge nodes and thus not being able to proceed further (as we block ICMP across our edge). ``` 14 be7.bhs-vac1-a75.qc.ca (192.99.146.147) 416.777 ms 509.795 ms 432.394 ms ``` BHS in this case indicates **Beauharnois** - our North American proxy location, and VAC indicates the mitigation infrastructure utilized at this facility. During normal circumstance (i.e. when connected over ethernet), the computer used to perform this traceroute typically experiences 60ms to this VAC hop. Do you remember the `302.809ms` probe we saw on the first hop of our trace? Our unstable connection to our internal network has unfortunately propagated its way to the rest of our Traceroute, resulting in the high latency on hop 14 - therefore adding \~300ms to what would should normally be within the 60-70ms range. Networks are only as stable as the weakest link - and in our case, our weakest link is indeed our internal (home) network. The BGP (border gateway protocol) is the system that glues the internet together, and is responsible for making routing decisions between switches and routers on the internet. In normal circumstances, BGP will route around these problems automatically when high latency or packet loss becomes and issue between major PoPs (point of presences) on the internet. However in our case, there really isn't anything to route around because we haven't routed anywhere yet - the high latency is present within our LAN itself, and our only solution at this point would be to diagnose why this could be happening. ### Diagnosing propagation delay Since our high latency occurred within our internal network itself - it would be a good idea to determine why this is happening. After all, WiFi isn't totally stable from a jitter standpoint, especially considering this trace was performed with many other clients connected - and presumably other appliances or electronic equipment interfering as well. For residential connections, you should first try and see if the high latency is still present when performing a traceroute over Ethernet, which is not prone to the inherent pitfalls introduced with Wifi. If the high latency still occurs over Ethernet, the most probable scenario is a congestion issue within the ISP your player(s) are using itself. During high traffic periods of the day, sometimes an ISP's downstream link to its distribution routers may be overwhelmed, and thus forwarding and propagation delays will be an inherent issue that cannot be solved without contacting the ISP's network engineers to further diagnose the issue. # Connection Complaint Policy We try our best to deliver the most performant network we can for our customers. Unfortunately, there are some things are are simply out of our control (congestion on ISPs, unstable mobile data signal, microwave ovens turned on, or similar). Therefore, TCPShield requires the following before considering a connection degradation event: * A minimum of 5 players in similar region experiencing similar issue(s) * A traceroute from at least one player, to TCPShield\ `tracert play.yourserver.com` * Source IP or usernames from at least 3 players. TCPShield will not impose fixes for one-off connection complains, and must see evidence of widespread issues. The internet is large and complex, and does not route ideally at times. As such, imposing fixes for one player may create unexpected issues for others. # Sentry Tunnel Features As TCPShield expands its infrastructure beyond Minecraft, we’re proud to introduce **Sentry Tunnel** – the next evolution in clean traffic delivery, launching from April 2025. **Sentry Tunnel** is our high-performance, [**VXLAN-based**](https://www.juniper.net/us/en/research-topics/what-is-vxlan.html) tunneling solution built for modern cloud-scale networking. It allows us to protect and forward **any TCP or UDP traffic** with unmatched flexibility, speed, and compatibility. Whether you're running multiplayer game servers, real-time applications, or custom services, Sentry Tunnel delivers clean traffic with minimal latency and maximum reliability. ## What is the Sentry Tunnel? Sentry Tunnel leverages **VXLAN (Virtual Extensible LAN)** technology under the hood, but brings modern branding and engineering practices to offer you a refined and production-grade clean traffic solution. ### 1. Optimized for Anycast and Scrubbing Efficiency Sentry Tunnel is stateless and UDP-based, making it a perfect match for our Anycast infrastructure: * **Always connects to the nearest scrubbing center**, minimizing latency and packet loss. * **Instant failover** between locations — no reconnections or handshakes required.\\. * Supports **multi-point tunnel topologies**: multiple TCPShield nodes forward clean traffic to your origin without needing to manage dozens of individual tunnels. ### 2. **Simulated Local Network Between Edge and Origin** When using TCPShield’s VXLAN tunneling, your backend server receives traffic **as if it's on the same local network (LAN)** as the Sentry node — even if they are physically separated by thousands of miles. This architecture provides **multiple real-world performance and integration benefits**, especially for latency-sensitive services like Minecraft. * **Real IP Visibility:** VXLAN preserves the player’s original IP without relying on headers, enabling accurate banning, geolocation, and DDoS protection. * **Stable, Direct Connections:** The backend maintains full control over TCP/UDP state, ensuring predictable behavior and reduced risk of timeouts or packet loss. * **Simplified Backend Integration:** Sentry nodes behave like local devices, making it easy to plug into existing firewalls, monitoring tools, or containers. ### 3. Higher cost efficiency Compared to traditional game-specific proxies (like our Minecraft protection), Sentry Tunnel supports **many tenants on a single IP**: * Protect diverse services and ports on the same machine — even if they’re using different protocols. * Example: protect Minecraft servers on ports `25565–25577`, and FiveM servers on `30120–30127` — all behind one protected IP. * Define Layer 7 protocol filters per port range using our intuitive firewall panel, or automate the setup via API. ### 4. Minimal Overhead, Maximum Performance Sentry Tunnel introduces only \~50 bytes of overhead per packet, while delivering major performance benefits: * **Hardware offload** support ensures packets are processed at line rate with minimal CPU load. * **UDP encapsulation** unlocks networking features like Large Receive Offload (LRO) and Generic Segmentation Offload (GSO). * Delivers **multi-gigabit throughput** with low operational cost. ### 5. Protocol-Agnostic – Beyond Just Minecraft Sentry Tunnel is not limited to any single protocol or application. Thanks to VXLAN’s Ethernet-over-IP design, it supports: * **IPv4, ARP, multicast**, and even broadcast-based protocols. * **Exotic or legacy game engines**, real-time UDP apps, or custom multiplayer protocols. * Works **seamlessly behind NAT**, supporting cloud platforms like AWS, GCP, and Azure, or home-hosted setups. If your application uses TCP or UDP, **Sentry Tunnel can protect it** — no sweat. ### 6. Better than GRE: A Refined Solution for Modern Needs GRE has long been used in clean traffic tunneling — but it’s showing its age. Sentry Tunnel improves on every front: | Feature | GRE | Sentry Tunnel (VXLAN-based) | | ------------------------- | --------- | --------------------------- | | NAT Traversal | ❌ Poor | ✅ Excellent (UDP) | | Multi-Tenant Isolation | ❌ Limited | ✅ Up to 16M VNIs | | Hardware Offload | ❌ Rare | ✅ Widely Supported | | Performance on Multi-core | ❌ Poor | ✅ Optimized | | Segmentation Support | ❌ None | ✅ Built-in | Sentry Tunnel delivers all the benefits of GRE — and far more. *** ### 7. Protocol‑Enforced Tunnel Firewall Take your tunnel security to the next level with our **ProtoGuard Firewall**, a cutting‑edge, protocol‑aware layer that ensures port traffic strictly conforms to expected patterns. * **Protocol‑aware filtering per port or range**\ Admins can define specific protocols—e.g., FiveM, CS2, Minecraft, custom UDP/TCP-based services—on selected ports or ranges. Only traffic matching the configured protocol is allowed; everything else is automatically dropped.\ *Example*: Lock down port `30120–30125` exclusively to FiveM traffic—any non‑FiveM packets will be dropped immediately. * **Built for user convenience**\ Configure filters effortlessly through the panel or automate them via API. Set protocol rules as you define your tunnel or update them at any time—no advanced firewall scripting required. * **Expandable protocol library**\ Our supported‑protocol catalog is ever‑growing. Starting with popular services like FiveM, CS2, and standard TCP/UDP protocols, we’re continually adding more. Future releases will include additional game and application protocols—ensuring your tunnel stays locked down and future‑proof. *** While VXLAN Sentry Tunnel already offers stateless, port‑agnostic forwarding and high‑performance features, adding ProtoGuard™ transforms it into a smart firewall that actively enforces layer‑compliant traffic—greatly reducing the attack surface and mitigating misconfiguration or abuse.
User scenario: You're running both a FiveM server on `30120–30125` and a CS2 server on `27015–27020` using the same Sentry Tunnel. Set ProtoGuard™ to allow only FiveM on its ports and CS2 on its. Any unrelated packets are automatically dropped before reaching your origin, cutting off noise, scans, or malformed traffic.
## What This Means for TCPShield Users 1. **Expanded Game & App Support**: Protect any TCP/UDP-based service, not just Minecraft. 2. **Lower Latency**: Our Anycast tunnel endpoints ensure traffic always routes through the nearest scrubbing node. 3. **Scalable Protection**: Clean traffic is delivered efficiently across global tenants with flexible routing and isolation. *** ## Ready to Deploy Our Sentry Tunnel solution is now available for public access. If you're interested in enabling VXLAN-based clean traffic delivery for your service, contact us over at our support Discord or head to the [setup page](/vxlan/sentry-tunnel-for-rathena-ragnarok) to get started. # Sentry Tunnel General Setup General Setup Guide The setup process does require the users to have some knowledge regard networking to effectively trouble shoot any issues that comes up. To help you better visualize the process, we have provided steps by steps guide on how to setup TCPShield VXLAN for Bedrock, FiveM and rAtherna (Ragnarok) servers, with other type of services coming soon. [rAthena/Ragnarok](/vxlan/sentry-tunnel-for-rathena-ragnarok) [Bedrock/Geyser.](/vxlan/sentry-tunnel-for-bedrock-geyser-pocketmine-voicechat) [FiveM/GTA Online.](/vxlan/sentry-tunnel-for-fivem-gta-online)\ \ Keep in mind that the setup process is pretty much the same across all applications. But if you run into issues along the way, please head to our Discord channel and open a ticket. ### Before you begin: **a. Basic requirements** * **Root access (or full sudo) on a Linux server** so you can create/manage network interfaces, routes, and firewall rules. * A server environment where you’re allowed to use kernel networking features (VXLAN is a Linux networking feature, and Sentry Tunnel is UDP-based). **b. Who likely can’t use it** * **Shared hosting / managed game hosting** where you *don’t* have root access or are blocked from creating custom network interfaces. (In those setups, you typically can’t bring up a VXLAN interface at all.) **c. What about Windows Server?** * You *can* still protect a Windows-hosted service, but it’s usually **more complicated**: you’ll typically run a **Linux proxy in front** (VPS or dedicated) to terminate the VXLAN tunnel and then forward traffic to the Windows server. This adds an extra component/hop and extra routing rules compared to a direct Linux origin. ## 1. Tunnel Creation Head to our dashboard and navigate to the Tunnels section on the left corner, then click on New Tunnel:
You’ll see the following fields: 1. **Name**: A custom label for your tunnel, use something descriptive. 2. **Endpoint**: The external IP address of your backend server (e.g., your VPS or physical machine). This is where the VXLAN tunnel will forward traffic.
Protecting multiple ports Since VXLAN tunnel doesn't care which port your service is running on (port-agnostic), the Endpoint should only contains your backend IPv4. Hence you can have multiple services / gameserves being protected behind a single Tunnel instance, which is very useful for scalability.
1. **Locations**: The location will always be Anycast for optimal global routing. 2. **Port**: A port will be automatically assigned from the range 32768–60999. This is the port our VXLAN tunnel will use to communicate with your backend. No need to change this unless you have specific routing or firewall requirements.
VXLAN PORT This assigned port is **NOT** your service port (e.g., **6900** for Ragnarok or **25565** for Minecraft). Your application will continue to listen on its usual port. The VXLAN tunnel just forwards traffic to that original port via the backend IP.

Tunnel creation

## 2. Tunnels Overview Once the tunnel is created, you'll be redirected to the Overview page, which will show all of the necessary information:
* **Public IP**: The dedicated IP your users will connect to (e.g., 104.234.6.228). * **VXLAN Port**: The port assigned for VXLAN traffic (e.g., 38378). * **Endpoint**: The backend IP of your game or application server. You can change this value whenever you like, but make sure to also re-run the Setup Script when you do so.
Changing your Endpoint Settings: Once you have updated your backend IPv4, the page should refresh and you will see a new Setup Script being generated.
* **Setup Scrip**t: At the bottom of the Overview page, you’ll find a Setup Script that looks like this. ``` ip link add vxlan_2116 address 12:cc:6c:3d:95:b6 type vxlan id 2116 remote 198.178.119.30 dstport 38378 nolearning ip addr add 104.234.6.228/16 dev vxlan_2116 ip link set dev vxlan_2116 mtu 1450 up ip route add default via 104.234.253.228 dev vxlan_2116 table 1688 ip rule add from 104.234.6.228 lookup 1688 ``` We'll include explanation for each line in the script for anyone interested: {% tabs %} {% tab title="1. Interface creation" %} ```bash ip link add vxlan_2116 address 12:cc:6c:3d:95:b6 type vxlan id 2116 remote 198.178.119.30 dstport 38378 nolearning ``` * `vxlan_2116` : Interface name, named after the VXLAN ID * `address 12:cc:6c:3d:95:b6` : assigned MAC address for the virtual interface * `id 2116` : Unique tunnel identifier for this customer * `remote 198.178.119.30` : The other end of the tunnel (TCPShield's side) * `dstport 38378` : VXLAN traffic is encapsulated over **UDP** on this port * `nolearning` : Disables MAC learning — only uses static routes {% endtab %} {% tab title="2. IP" %} ```bash ip addr add 104.234.6.228/16 dev vxlan_2116 ``` * Gives the tunnel interface a **TCPShield-owned IP** (`104.234.x.x` block) * The `/16` means the customer's server is now part of TCPShield's `104.234.0.0/16` network * This is the IP that **players connect to**, not the customer's backend IP {% endtab %} {% tab title="3. MTU" %} ```bash ip link set dev vxlan_2116 mtu 1450 up ``` * MTU set to **1450** (not standard 1500) to account for VXLAN encapsulation overhead (\~50 bytes of UDP/IP/VXLAN headers) * `up` activates the interface * To help players with weaker connections, servers can reduce this value to 1400 or lower. {% endtab %} {% tab title="4. Route " %} ```bash ip route add default via 104.234.253.228 dev vxlan_2116 table 1688 ``` * Adds a default route inside a **separate routing table (`1688`)** — not the main table * `104.234.253.228` is TCPShield's gateway on the other end of the tunnel * All traffic matching this table exits through the VXLAN tunnel back to TCPShield {% endtab %} {% tab title="5. Policy" %} ```bash ip rule add from 104.234.6.228 lookup 1688 ``` * **Key line** — tells the kernel: *"if a packet's source IP is `104.234.6.228`, use routing table `1688`"* * This ensures **reply traffic** goes back through the tunnel, not out the customer's regular internet connection {% endtab %} {% endtabs %} ## 3. Firewall configuration: Most cloud providers have a firewall enabled by default. To make sure your backend works correctly, please follow the steps in our guide (linked below) to allow the necessary ports. If you’re not sure how to do this, you can also check your cloud provider’s help articles or look up guides for `ufw` or `iptables`. For customers using Pterodactyl, ensure that you open the VXLAN port on the panel itself. This can be done by navigating to the **Network** tab and selecting **Create Allocation**. For more information, visit this [guide](https://knowledgebase.aquatis.host/books/pterodactyl-guides/page/how-do-i-addopen-a-server-port-on-pterodactyl). ## 4. Setting up Sentry Tunnel: Copy and run your Setup Script. Pasting it directly in the terminal should be fine, or you can create a custom `.sh` script in case you need to re-run it later. You can verify that the tunnel was created by running: ``` ip -s link show vxlan_2116 ``` Example output: ``` root@admin:~# ip -s link show vxlan_2116 472: vxlan_2116: mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 12:cc:6c:3d:95:b6 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 648 7 0 0 0 0 ``` And with it: * Your server will now be reachable via the assigned public IP. For example, your TeamSpeak server is reachable via `104.234.6.228:9987` or your Lineage server via `104.234.6.228:2160` etc etc. * You can also head to our [Setup Checklist](https://docs.tcpshield.com/vxlan/common-issues-and-debugging#id-1.-vxlan-setup-check-list) page to verify your setup. If run into any issue along the way, either head to our [Debugging Page](/vxlan/common-issues-and-debugging) or make a ticket on our [Discord](https://discord.com/invite/tcpshield) channel. ### 5. Recommend: Configure our ProtoGuard Firewall: On our Sentry tunnel we have developed strict mitigation for selected games and services,imply head to our Firewall Tab to enable them: **Fitler Name**: You can select the desired protocol here. Traffic that does not conform to said protocol will be dropped. At the moment we offer ProtoGuard Firewall for: * FiveM * Simple Voice Chat * Minecraft Bedrock/Geyser * ARK Survival Evolved * Counterstrike: Global Offensive (including CS2) * Rust * TeamSpeak * Valheim * RAN Online With more coming later.\ **Start Port/End Port**: You can insert port range where the filter would apply,

Firewall Selection Page

# Sentry Tunnel for rAthena/Ragnarok Follow this guide to protect your gameserves with TCPShield This guide explains how to create and configure a Sentry/VXLAN tunnel, using a Ragnarok Online server as an example (rAthena emulator running on `108.61.149.182:6900`). ## 1. Setup Follow the Sentry Tunnel General Setup guide [here](https://docs.tcpshield.com/vxlan/sentry-tunnel-general-setup#id-1.-tunnel-creation). ## 2. Whitelist VXLAN and Backend Ports Your VPS/Dedicated server might have a firewall which is blocking outside connections by default (or a [Security Group](https://docs.tcpshield.com/vxlan/pages/631Mayag431M2l0f1dAD#id-1.2-firewall) put in place by your Cloud Provider). In this case, it's important to make sure your server port and the VXLAN's port are both accepting connections. This can be achieved by using `UFW` or `iptables`. #### Using UFW ``` ufw allow /udp ufw allow /tcp ``` Then verify the status by running: ``` ufw status ``` #### Using iptables ``` iptables -A INPUT -p udp --dport -j ACCEPT iptables -A INPUT -p tcp --dport -j ACCEPT iptables -A OUTPUT -p tcp --sport -j ACCEPT iptables -A OUTPUT -p udp --sport -j ACCEPT ``` Then verify your configuration by running: ``` iptables-save ``` ## 3. Execution Now you just need to run the provided script, once completed: * Your server will now be reachable via the assigned public IP (e.g., 104.234.6.128). * The server latency depends on the Anycast region and distance from your users. You can verify that the tunnel was created by running: ``` ip -s link show vxlan_ ``` Originally I have the Ragnarok server running on: `108.61.149.182:6900` After running the setup script, the players can now connect using: `104.234.6.128:6900`

Example on the client's side connection

As you can see, only the IP changes — the service port remains the same. Only the address needs to be updated.

Final result

And that's it, your Sentry tunnel is now fully operational. Congratulations! You can now run your server with confidence, knowing that it's protected by TCPShield. If you encounter any issues during setup or operation, please refer to our [Debugging Guide](/vxlan/common-issues-and-debugging) for troubleshooting tips and common pitfalls. # Sentry Tunnel for Bedrock/Geyser/PocketMine/VoiceChat For everything Bedrock related. For customers using the Pterodactyl panel, you may need to contact us during the setup process, as Pterodactyl reserves all private IP addresses, which can prevent the creation of the tunnel. Refer to this [debug section](https://docs.tcpshield.com/vxlan/pages/631Mayag431M2l0f1dAD#id-2.-error-nexthop-has-invalid-gateway). ## 1. Ensure a working Geyser Instance Before proceeding, make sure your Geyser instance is running. Follow the instructions in the [Geyser documentation](https://geysermc.org/wiki/geyser/setup/) to set up your server. In this example, we have a Bedrock server up and running on `108.61.149.182:19132` :

Bedrock server using Geyser-Standalone

For TCPShield customers running PocketMine MP, please consult their [official guide](https://doc.pmmp.io/en/rtfd/installation.html). ## 2. Create your Sentry Tunnel Follow this Sentry Tunnel General Setup [guide](/vxlan/sentry-tunnel-general-setup). After creating the tunnel, navigate to the bottom of the Overview page, then copy and run your VXLAN creation script. If you encounter any errors, refer to the [troubleshooting section](/vxlan/common-issues-and-debugging). To verify that the tunnel was created successfully, run the following command: ``` ip -s link show vxlan_ ``` Example output: ``` root@admin:~# ip -s link show vxlan_47 418: vxlan_47: mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 12:cc:cb:ab:1f:e8 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 341644143 2036858 0 0 0 0 TX: bytes packets errors dropped carrier collsns 53378176 387353 0 0 0 0 ``` Ensure both the VXLAN port and your backend port are properly whitelisted. You can achieve this using either UFW or iptables. This step might not be necessary, but worth mentioning nonetheless. ### Using UFW ``` ufw allow /udp ufw allow /tcp ``` Then verify the status by running: ``` ufw status ``` ### Using iptables ``` iptables -A INPUT -p udp --dport -j ACCEPT iptables -A INPUT -p tcp --dport -j ACCEPT iptables -A OUTPUT -p tcp --sport -j ACCEPT iptables -A OUTPUT -p udp --sport -j ACCEPT ``` Then verify your configuration by running: ``` iptables-save ``` {% hint style="warning" %} IMPORTANT: For customers using Pterodactyl, ensure that you open the VXLAN port on the panel itself. This can be done by navigating to the **Network** tab and selecting **Create Allocation**. For more information, visit this [guide](https://knowledgebase.aquatis.host/books/pterodactyl-guides/page/how-do-i-addopen-a-server-port-on-pterodactyl). {% endhint %} ## 4. Update the config file ### 4.1 Geyser Next, update the `address` (under the `Bedrock` section) in the Geyser configuration file to the public IP address of your VXLAN tunnel. For example, if your public IP is `104.234.6.128`, make the necessary changes to the config. The port of the server stays the same, aka `19132`.

Update Geyser's backend IP Address

Also make sure `enable-proxy-connections: false` . On newer Geyser version, this setting is also called `haproxy-protocol`, but make sure you only edit the one located inside the `bedrock` section. After restarting the server, double-check that the service is running properly by running the following command: ``` netstat -plunt | grep 104.234.6.128 ``` The output should look similar to this: ``` root@admin:~# netstat -plunt | grep 104.234.6.128 udp 0 0 104.234.6.128:19132 0.0.0.0:* 1546258/java udp 0 0 104.234.6.128:19132 0.0.0.0:* 1546258/java ``` ### 4.2 PocketMine MP By default PocketMine will always listen on `0.0.0.0` , hence you have to navigate to your `server.properties` and update `server-ip` to the tunnel Public IP Address. If not available, simply add it in the file. Example config: ``` #Properties Config file #Tue Jul 8 11:04:48 UTC 2025 language=eng motd=TCPShield Test server-port=19132 server-ip=104.234.6.128 server-portv6=19133 gamemode=SURVIVAL ... ``` Restart the server and you should see the MP server is listening on the correct interface: ``` root@admin:~# netstat -plunt | grep 104.234.6.128 udp 0 0 104.234.6.128:19132 0.0.0.0:* 1095804/PocketMine- ``` ## 5. Final Step At this point, the connection to your Bedrock server will be using the public IP `104.234.6.128`. Create an A record that points directly to this IP address on your preferred DNS manager:

The Geyser instance running on 104.234.6.128:19132

Your PocketMine MP instance running on 104.234.6.128:19132

And that's it, happy gaming! ## 6. Voice chat setup: {% hint style="info" icon="square-exclamation" %} **IMPORTANT**: Since VXLAN is fairly complicated for most users, if you just require voice chat support and nothing else, please contact our support staffs on Discord to have it deployed. {% endhint %} ### 6.1 [Simple Voice Chat](https://modrinth.com/plugin/simple-voice-chat/versions) There are 2 values to update:\ \- To make sure SVC's listening on the correct IP address, `bind_address` should be using the tunnel `public IP` . \- You would then specifiy the `voice_host` to `tunnel_IP:port` so the clients can connect to it.\ Example config file: ``` # Simple Voice Chat proxy config v2.6.4 # The port number to use for the voice chat communication. # Audio packets are always transmitted via the UDP protocol on the port number # specified here, independently of other networking used for the game server. # Set this to '-1' to use the same port number as the one used by the proxy. port=24454 # The proxy IP address to bind the voice chat to # Leave blank to use the proxy bind address # To bind to the wildcard IP address, use '*' bind_address=104.234.6.128 # The hostname that clients should use to connect to the voice chat # This may also include a port, e.g. 'example.com:24454' or just a port, e.g. '24454' # Do NOT change this value if you don't know what you're doing voice_host=104.234.6.128:24454 # If the voice chat proxy server should reply to external pings allow_pings=true ``` ### 6.2 [Plasmo Voice](https://plasmovoice.com/) Shout out to a very detailed [documentation](https://plasmovoice.com/docs/server/advanced/) on their side. To setup PlasmoVoice with VLXAN tunnel, you need to:\ \- Change the IP and port of \[host] and \[host.public] to match your VXLAN's `public IP` and your specific `port` .\ \- Example config: ``` [host] # The IP:PORT your voice chat instance is running on ip = "104.234.6.128" port = 25577 [host.public] ip = "104.234.6.128" # The IP of the public voice chat server port = 25577 # The port of the public voice chat server ```
# Sentry Tunnel for FiveM/GTA Online VXLAN Setup for FiveM server In this guide, I will walk you through the process of setting up a Sentry Tunnel for a FiveM server running on Windows 11, using the txAdmin panel. **Notes**: **Sentry Tunnel/VXLAN requires a Linux Server.** Hence, I will also include instructions for setting up a Linux proxy in front of the Windows server. If you're already running your FiveM server on a Linux OS, simply skip the proxy creation step. ## 1. Verify that the server is running: In my example, the server is running and reachable on `103.120.39.17:30120`
## 2. Tunnel Creation Follow the Sentry Tunnel General Setup [guide](https://docs.tcpshield.com/vxlan/sentry-tunnel-general-setup#id-1.-tunnel-creation). #### **2.1 FOR LINUX SERVER**: Ensure both the backend port (`30120`) and the VXLAN port (`34251`) are open and accepting connections. You can refer to this [guide](https://docs.tcpshield.com/vxlan/pages/tNANL6U2oTTO0aX4rw6H#id-4.-whitelist-vxlan-and-backend-ports) for further instructions. Copy and run the setup script located at the bottom of the page. Verify the tunnel creation by running the following command: ``` ip -s link show vxlan_ ``` If the tunnel was successfully created, you will see output similar to this: ```python root@admin:~# ip -s link show vxlan_47 418: vxlan_47: mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 12:cc:cb:ab:1f:e8 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 341644143 2036858 0 0 0 0 TX: bytes packets errors dropped carrier collsns 53378176 387353 0 0 0 0 ``` At this point, you should be able to ping the private IP address: ```python root@admin:~# ping 172.18.128.2 PING 172.18.128.2 (172.18.128.2) 56(84) bytes of data. 64 bytes from 172.18.128.2: icmp_seq=1 ttl=64 time=51.6 ms 64 bytes from 172.18.128.2: icmp_seq=2 ttl=64 time=50.9 ms 64 bytes from 172.18.128.2: icmp_seq=3 ttl=64 time=50.0 ms 64 bytes from 172.18.128.2: icmp_seq=4 ttl=64 time=50.0 ms ``` Finally, proceed to **Step 4** to complete the setup. #### **2.2 FOR WINDOWS SERVER**: Head to step 3 to create your NGINX Proxy. ## 3. NGNIX Proxy Creation {% hint style="warning" %} Skip this step if you already have a Linux server. {% endhint %} *This goes without saying that the endpoint IP address of your VXLAN tunnel should be the Linux's server IP.* Since the VXLAN tunnel can only be created on a Linux server, as a Windows user, you will need access to a Linux server. We recommend using a reputable hosting provider. In this example, the proxy IP address is **`108.61.149.182`**. Navigate to your `nginx.conf` file, which can be found at one of these locations: * `/usr/local/nginx/conf/nginx.conf` * `/etc/nginx/nginx.conf` n Use your preferred editor (e.g., `nano`), and add the following configuration: (*It goes without saying that you should replace the corresponding IP addresses to match your own*). ```python stream { upstream backend { server 108.61.149.182:30120; # your proxy IP address } server { listen 104.234.6.128:30120; # your VXLAN tunnel public IP proxy_pass 103.120.39.17:30120; # your backend IP address } server { listen 104.234.6.128:30120 udp reuseport; proxy_pass 103.120.39.17:30120; } } ``` Reload your NGINX server: `service nginx reload` Now, return to **Step 2** and run the setup script. Follow the instructions for the Linux server. ## 4. Update the config file In your server.cfg file, change it to something similar to **this example**: ```python set sv_forceIndirectListing true set sv_proxyIPRanges "104.234.6.128/32" set sv_endpoints "104.234.6.128:30120" ``` {% hint style="danger" %} For Pterodactyl user you might need to have `set sv_forceIndirectListing false` to avoid an issue with serverlist query: {% code overflow="wrap" expandable="true" %} ``` Server list query returned an error … The SSL connection could not be established … Connection reset by peer ``` {% endcode %} {% endhint %} You might want to also specify the UDP endpoint for your server: ```coffee endpoint_add_udp 104.234.6.128:30120 ``` {% hint style="warning" %} If you are using a domain, make sure it's pointing to the VXLAN public IP address, which in this case is `104.234.6.128` {% endhint %} And that should be pretty much everything you have to do. # Common issues and Debugging This page provide the most common pitfalls users might have with VXLAN tunnel. This page is largely under construction as we are gathering more edge cases. Your feedback is much appreciated. ## 1. VXLAN Setup Check List It is crucial to ensure that you can directly connect to the services or games you are hosting using their IPv4 address and port. For instance, in this setup documentation, the [Ragnarok server](/vxlan/sentry-tunnel-for-rathena-ragnarok#docs-internal-guid-01454216-7fff-023d-1756-215a6f207bb2) was accessible via `108.61.149.182:6900`. If your VXLAN tunnel is not functioning correctly, several potential causes may exist. Below are some best practices to follow to confirm that your service is properly set up and running. ### 1.1. Verifying tunnel creation After running the setup script, you can run the following commands to check your tunnel configuration: 
ip -s link show vxlan_<ID>
Example output: ``` root@admin:~# ip -s link show vxlan_47 418: vxlan_47: mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 12:cc:cb:ab:1f:e8 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 543784518 3037392 0 0 0 0 TX: bytes packets errors dropped carrier collsns 154324621 1408584 0 0 0 0 ``` You should see 0 under the errors and dropped columns. Any other numbers would indicate packets being dropped (possibly from a firewall). ### 1.2. Interface traffic To verify that your VXLAN tunnel has been properly established, you can ping tunnel's `Public IP Address` , the reply should looks something like this (with <1ms latency): ``` root@admin:~# ping 104.234.6.128 PING 104.234.6.128 (104.234.6.128) 56(84) bytes of data. 64 bytes from 104.234.6.128: icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from 104.234.6.128: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from 104.234.6.128: icmp_seq=3 ttl=64 time=0.060 ms 64 bytes from 104.234.6.128: icmp_seq=4 ttl=64 time=0.061 ms ``` You can also check the output of: ``` ip route ``` ``` root@admin:~# ip route ... 104.234.0.0/16 dev vxlan_2116 proto kernel scope link src 104.234.6.228 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.89 ... ``` If the tunnel was properly created, you will see your public IP address in the output. ### 1.3 Firewall Configuration There are two potential scenarios: 1. **Cloud Provider Firewall**: Major cloud providers like Linode, AWS, and Azure have default security group or firewall settings that may block traffic before it even reaches your VPS. In this case, you can navigate to your provider's control panel and allow traffic from [TCPShield](https://tcpshield.com/v4) to your backend ports. 2. **Server Firewall**: If you are using a server firewall such as `netfilter`, `iptables`, or `ufw`, you will need to open both the backend port and the VXLAN port to accept external connections, or, in rare cases, explicitly whitelist the VXLAN interfaces. Using `iptables` to Accept Connections to Your Backend Port ``` iptables -I INPUT -p udp --dport -j ACCEPT iptables -I INPUT -p tcp --dport -j ACCEPT iptables -I OUTPUT -p tcp --sport -j ACCEPT iptables -I OUTPUT -p udp --sport -j ACCEPT ``` {% hint style="warning" %} Notes: To remove these rules, simply replace `-A` with `-D` to delete them. {% endhint %} Using `UFW` : 
ufw allow <port>/udp
ufw allow <port>/tcp
{% hint style="warning" %} To delete these rules, use the following command: `sudo ufw delete allow /udp`\ `sudo ufw delete allow /tcp` {% endhint %} **Whitelisting VXLAN Interface (Optional)** Although this step is typically *not necessary*, you can whitelist the VXLAN interface explicitly using `iptables`: ``` iptables -I FORWARD -i vxlan_ -j ACCEPT iptables -I FORWARD -o vxlan_ -j ACCEPT ``` Using `UFW`: ``` sudo ufw route allow in on vxlan_ to any sudo ufw route allow out on vxlan_ to any ``` ## 2. Error: Nexthop has invalid gateway (Pterodactyl / Wings). If you're running **Pterodactyl** (or other Docker-based services), you might encounter the error: > **Nexthop has invalid gateway** This usually happens when the **VXLAN tunnel attempts to bind to an IP address** that is already reserved by Docker. For example, Pterodactyl’s default bridge network (`pterodactyl0`) may overlap with the subnet used by VXLAN (`172.18.0.0/16`), causing the tunnel setup to fail. To debug: 1. **Check the Local IP Address for VXLAN**: It should resemble something like `172.18.132.2`. 2. Run `ip route` and you may see an entry like: ``` 172.18.0.0/16 dev pterodactyl0 proto kernel scope link src 172.18.0.1 ``` In this case, the `172.18.132.2` IP address might conflict with the Docker network configurations. For example, if the `pterodactyl0` interface is using `172.18.0.1`, this could block the gateway you are trying to use (`172.18.132.2`), as it lies within the Docker subnet. #### **✅ SOLUTION: Switch Pterodactyl to use host networking** To prevent Docker from reserving IPs that interfere with your VXLAN setup: 1. **Edit Pterodactyl config**\ Open `/etc/pterodactyl/config.yml` and modify the Docker networking section: ``` docker: network: name: host network_mode: host ``` 2. **Restart the network stack and Wings daemon**
``` systemctl stop wings docker stop $(docker ps -q) docker network rm pterodactyl_nw systemctl start wings ``` This change puts all containers on the **host network**, removing the isolated Docker bridge and preventing subnet conflicts. Your VXLAN tunnel should now initialize without errors. 3. **Forcing outbound traffic to use the right path** We need to check which block Pterodactyl is using to route outbound traffic: ``` ip route | grep pterodactyl ``` Assuming this output: ``` 172.20.0.0/16 dev pterodactyl0 proto kernel scope link src 172.20.0.1 ``` You should add this iptables rule: ``` iptables -t mangle -A PREROUTING -s 172.20.0.0/16 -m conntrack --ctstate ESTABLISHED,RELATED -j MARK --set-xmark 0x9 ``` Which marks packets from the 172.20.0.0/16 network that belong to existing connections so that your routing rules know “this traffic belongs to TCPShield’s VXLAN, send it back through the tunnel.” ## 3. Tunnel deletion In case you need to delete the tunnel and re-run the setup script, here is how: ``` ip link del dev vxlan_ ip rule del fwmark 9 table 200 ``` You can also remove the iptables rules in the script, by replacing `-A` and `-I` with `-D` , example: ``` iptables -t mangle -D OUTPUT -s 104.234.6.137/32 -j MARK --set-xmark 0x9 iptables -t mangle -D POSTROUTING -s 104.234.6.137 -j MARK --set-mark 0 ``` ## 4. VXLAN tunnel stopped working on server reboot Sometimes, after rebooting your VM or dedicated server, the VXLAN script may not re-run, causing the service to stop working. To fix this, you can set up a persistent service to automatically run the VXLAN script after each reboot. **Steps to Setup Persistent VXLAN Tunnel:** 1. Edit the `rc.local` file: ``` sudo nano /etc/rc.local ``` 2. Add the following lines to execute the VXLAN script at boot: ``` #!/bin/bash # rc.local - VXLAN auto setup at boot sleep 5 echo "VXLAN script executed" exit 0 ``` 3. Save and exit the editor (`Ctrl+X`, then `Y` to confirm). 4. Make the script executable: ``` sudo chmod +x /etc/rc.local ``` Now, the VXLAN script will run automatically after each reboot, ensuring that the tunnel is re-established. ## 5. Disable Reverse Path Filtering By default, most Linux distributions have `rp_filter` (Reverse Path Filtering) enabled. This is a kernel security feature that drops packets if their **source address** does not match the expected interface route — a defense mechanism against IP spoofing. However, in setups using **VXLAN** or **asymmetric routing**, this behavior can cause **legitimate packets** to be dropped if the kernel thinks they arrived from the "wrong" interface. During a `tcpdump` capture, you may see packets coming in, but no responses being sent by the kernel. For example: ``` root@admin:~# sudo tcpdump -nni any udp port 19132 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:15:30.707370 vxlan_47 In IP 14.231.20.10.62338 > 104.234.6.137.19132: UDP, length 33 15:15:43.571573 vxlan_47 In IP 14.231.20.10.63192 > 104.234.6.137.19132: UDP, length 1172 15:15:44.084121 vxlan_47 In IP 14.231.20.10.63192 > 104.234.6.137.19132: UDP, length 1172 15:15:44.598862 vxlan_47 In IP 14.231.20.10.63192 > 104.234.6.137.19132: UDP, length 1172 ``` As shown above, there is only ingress traffic from `14.231.20.10`, but no outgoing traffic from our VXLAN interface `104.234.6.137`. This means the system is silently dropping the replies. To fix this, disable reverse path filtering for all interfaces and for your VXLAN interface specifically: ``` sysctl -w net.ipv4.conf.all.rp_filter=0 sysctl -w net.ipv4.conf.vxlan_.rp_filter=0 ``` This disables strict source route validation, allowing the system to accept packets even if their return path differs — which is common in tunneling setups like VXLAN. Once reverse path filtering is disabled, you should start seeing **bi-directional traffic** over your VXLAN tunnel. A successful exchange will show both incoming and outgoing packets during a `tcpdump` capture. Expected result: ``` root@admin:~# sudo tcpdump -nni any udp port 19132 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 20:02:32.691465 vxlan_47 In IP 14.231.20.10.55407 > 104.234.6.137.19132: UDP, length 1164 20:02:32.691550 vxlan_47 In IP 14.231.20.10.55407 > 104.234.6.137.19132: UDP, length 1164 20:02:32.691665 vxlan_47 In IP 14.231.20.10.55407 > 104.234.6.137.19132: UDP, length 1112 20:02:32.696211 vxlan_47 Out IP 104.234.6.137.19132 > 14.231.20.10.55407: UDP, length 43 20:02:32.726227 vxlan_47 Out IP 104.234.6.137.19132 > 14.231.20.10.55407: UDP, length 550 ``` # TCPShield API Information about the API provided for TCPShield users. The process for integration against the TCPShield API is very easy. We have implemented full functionality and provide full support for our API for users with the pro plan and above. OpenAPI documentation is provided [here](https://swagger.tcpshield.com/). You can also find the repository where this information is hosted [here](https://github.com/TCPShield/api-docs). ### API Key Your API key can be grabbed from [your settings page](https://panel.tcpshield.com/pages/profile). ![](/files/-MWXYQe3M9Re_GCeLHLp) Generally speaking, your API key allows the caller to preform any action your normal account can. It goes without saying, but as a reminder, it is extremely important to keep your API key only in trusted hands. ### Examples List all networks: ``` curl -H 'X-API-Key: YOUR_API_KEY' https://api.tcpshield.com/networks ``` We will be providing API wrappers in more languages in the future. At this time, if you need support or have questions, the engineers of TCPShield would be happy to assist. ### Java API Our Java API is available at ### Important Information TCPShield reserves the right to restrict API access for anything we find malicious or overbearing on our systems. We also reserve the right to change the API without warning on the currently published endpoints. # Protect a website Using Cloudflare for web and TCPShield for Minecraft This guide will show how to have a website protected with Cloudflare and a Minecraft protected with TCPShield. This guide assumes you have a domain on Cloudflare already. ## Step 1: Login and remove existing records First, we need to protect our web server with Cloudflare. Let's log into Cloudflare and do that. ![Click here when you login](/files/-MWXY-jognDJUCg724aD) Now we will add our web server to Cloudflare. First we need to see if there are any DNS records already pointed to `@` (the base domain) or `www`. {% hint style="info" %} This guide will assume **example.com** is my domain {% endhint %} ![127.0.0.1 is an example in this case](/files/-MWXY5ZEkqaDS9Hqnbjd) ## Step 2: Add your web server IP Now, we will add our web server to cloudflare and proxy it. We can do that like this. ![Click here](/files/-MWXY8qPdSHtjCk5kGcz) ![Create the new DNS record](/files/-MWXYBLy8Eu2cJBuLLKr) {% hint style="info" %} If you would like `www.` to work as well, do the same thing again but replace `@` with `www` {% endhint %} ## Step 3: Create the SRV record Now we have protected our website on Cloudflare! Now we will make sure players can still connect with `example.com` using no subdomain. #### Step 3.1: Point TCPShield CNAME to a target Create a new DNS record like this ![Create a new DNS record for the target](/files/-MWXYHU2dvxQytnuIZuS) #### Step 3.2: Create the SRV Now we make it so `example.com` takes you to your server on Minecraft. Copy the steps below.

Copy the settings above

**IMPORTANT**: The port on the SRV record has to be **25565**. That's the port TCPShield is listening on, not your backend port. #### Step 3.3: Done It's as easy as one two three. # Wildcard DNS This documentation covers the setup of wildcard DNS. Wildcard DNS is beneficial for networks that need to dynamically generate subdomains for different servers or purposes, such as `xyz.domain.com`, `cracked.domain.com`, etc., without the need for individual DNS entries for each subdomain. This setup will guide you through the process and ensuring that all subdomains are secured and directed appropriately.
## Step 1: Verify your root domain: Follow this [step](https://docs.tcpshield.com/panel/panel-configuration#step-4-add-domains) in our documentation to verify your root domain. This step is crucial as it verifies ownership and controls DNS settings, which are needed for proper configuration and protection. ## Step 2: Adding your subdomain: On your DNS manager (we will be using Cloudflare in this demonstration), add a new CNAME record with this configuration: * Name: \* * Target: your protected CNAME target * Proxy status OFF

Example of a wildcard subdomai on Cloudflare

And that's all you have to do. {% hint style="info" %} If your configuration doesn't work immediately, it might be due to DNS [propagation](https://docs.tcpshield.com/miscellaneous/pages/zPcw0psLWpTEYm0nnIGl#id-3.-how-dns-propagation-works). {% endhint %} By following the steps outlined above, you can ensure that all subdomains under your domain are protected against DDoS attacks while maintaining flexibility in how you manage your DNS settings. # Protect a home hosted server TCPShield has a policy outlining home hosted servers on our network. Home hosted servers are allowed on our platform, as long as the following policy is adhered too. 1. Residential ISP's are extremely unreliable, so we make no guarantees about latency and performance while using TCPShield. 2. Residential connections have extremely low throughput and cannot handle network-intensive applications like hosting game servers and installing a DDoS mitigation network. 3. We will not provide assistance or support for home-hosted servers regarding latency, drops, and other connectivity issues. 4. We will assist with general configuration tips like DNS, plugin issues, and panel setup. 5. Detailed debugging from our staff is reserved for servers using a well known dedicated or virtual server provider (Ex: OVH, Hetzner, ReliableSite, etc) 6. Any attempt to lie or mislead TCPShield staff about the nature of your server is grounds for removal from the network. ## Common issues with home hosted server: ### 1. I don't have a domain, what should I do? There are several options to choose from. The most popular choice would be getting a free domain from [Freenom ](https://www.freenom.com)or [Cloudflare](https://www.cloudflare.com/en-ca/products/registrar/). After acquiring your domain, you can follow the setup process [here ](/panel/setup-process)as usual. ### 2. What address do I use for my backend set? The address on your backend set should be the **public** IP Address of your network. You can either google “What’s my IP Address” or go to to find it. One of the most common mistakes that we have seen is putting [RFC1918 ](https://datatracker.ietf.org/doc/html/rfc1918)(IP Address for Private Internets) as their backend. This will cause issues as your server can't be discovered on the public internet, hence our proxies cannot reach it. ### 3. My IP Address is Dynamic, what should I do? Services such as [No-IP](https://www.noip.com/) or Cloudflare Dynamic IP Address can help you with that. In this case, the “IP address” on your backend set is a valid hostname that reflects the current IP address your router is using, such as: `myrouter.ddns.net:25565`. That hostname resolves back to your home IP address, such as `71.57.77.154` – which is the **public** IP address provided for you by your ISP. After this you can use `myrouter.ddns.net:25565` as your backend, the rest of the setup can be done as normal. ### 4. Port forwarding [**Port Forwarding**](https://www.noip.com/support/knowledgebase/general-port-forwarding-guide) allows computers and services in the private networks (such as home networks) to connect over the internet with other devices on the public internet. If you are hosting your server on port `25565`, make sure that you have configured port forwarding on your router so that outside connections can reach that port. You can use a port check tool online such as [this](https://www.yougetsignal.com/tools/open-ports/) to ensure that your port is opened and ready to accept connections. {% hint style="info" %} Each manufacturer provides different steps for enabling port forwarding on their routers. Ensure that you consult the official documentation. {% endhint %} Following the initial setup, you have the option to verify the direct connection using your public backend IP address and port in the Minecraft client. Prior to conducting this test, it is essential to modify the TCPShield plugin's configuration by changing [`only-allow-proxy-connections`](/panel/tcpshield-plugin#configuration) to false. ### 5. Why does my home-hosted server have high ping? We understand that you have a home server with powerful hardware, and therefore think that it doesn’t make sense to spend extra to pay for a dedicated machine or a VPS. However, there are some disadvantages (this is not an exhaustive list) that come with a home-hosted server: * All traffic will be back-hauled to a single hub before being distributed somewhere else (Comcast put everything on Ashburn, or SHAW put all traffic in Seattle before going back to Canada for example), causing high latency in some areas as your connection has to make extra roundtrips. * Your traffic might be sent over legacy or copper-based last-mile segments instead of fiber, which introduces additional latency, noise, and potential packet loss compared to the short, high-quality links used inside data centers. * At any given time, your ISP (especially during peak hours) can announce different routing paths to offload traffic from their prioritized links, which can severely affect your server’s inbound and outbound performance and cause sudden spikes in latency or jitter. * Your ISP can rate-limit how much bandwidth you can transmit — either a limit on bps (bits per second) or pps (packets per second) — between each network, which means your home connection can have very low effective throughput when multiple users or applications are active. * You are most likely using a residential connection and don’t have the network hardware required (enterprise-grade NICs, core routers, or specialized appliances) to run more intensive applications or to handle bursts of concurrent connections reliably over time. * Your residential plan usually provides much lower upstream bandwidth and is heavily contended compared to the symmetrical, dedicated capacity in data centers, so your server can quickly become a bottleneck for players or users downloading world data, assets, or large responses from you. * Your home network typically experiences higher latency, jitter, and [bufferbloat](https://www.waveform.com/tools/bufferbloat) than a data-center or cloud environment; consumer routers and Wi-Fi gear often struggle under load, leading to lag spikes and inconsistent performance even when the raw “speed test” numbers look acceptable. * Your connection is more vulnerable to peak-time congestion and traffic shaping, as ISPs prioritize overall consumer traffic; this means your server may feel fine during off-hours but degrade significantly during evenings or weekends when the local segment of the network is saturated. * Your home IP address is often behind NAT or carrier-grade NAT and may be dynamic, which complicates inbound connectivity, breaks some protocols, interferes with port forwarding, and can cause unexpected downtime when your public IP changes or when the ISP changes how it translates your traffic. * Your home environment lacks the redundancy, SLAs, and professional monitoring that dedicated hosting providers offer; power outages, router crashes, or ISP maintenance can take your server offline without warning, whereas data centers are engineered for high uptime with backup power, cooling, and 24/7 operations. In general, we recommend using dedicated or virtual server vendors (Ex: Vultr, Hetzner, OVH, PNAP, ReliableSite, NFOServer, etc) if you are interested in hosting a server yourself. **Remember there is a reason why Enterprise hosting providers exist**.
# Account sharing Policies regarding MSPs and resellers on the TCPShield platform This page serves to outline our reseller and MSP (managed service provider) policy as of 2024/03/20. {% hint style="warning" %} At this time, reselling is **strictly prohibited** unless your business is an approved reseller or MSP. While we permit sharing of plans, any account found susceptible of reselling would be terminated from the platform. {% endhint %} ### Approved MSPs Currently, our approved MSPs and hosting providers are as followed: * cubeOps (Airee) * PebbleHost * Anjin LLC / 按針合同会社 * Zyphys / ZyphiCo * Hurbs LLC (Mason H.) * ОБЛАКО Delton (Delton Cloud) * Obsidian Servers ### Account sharing Account sharing (only on Premium plan) is generally permitted provided the following conditions are met: 1. Each user you wish to share is on their own network, and no two servers share the same network. 2. Domains on each network only correspond to the server that network was intended for. In other words, ExampleMC and HubCraft cannot share the same network. 3. The sub users understand that the account owner (master) has full visibility of networks under their account. 4. A maximum of three distict servers are sharing the plan. ### How to become an MSP To become an MSP, your business must fit the following criteria: 1. Domain registration date no earlier than than 1 year ago from time of applying. 2. Minimum of 10 customers which you are ready to onboard. 3. Provide formal documentation of either your registered LLC, or articles of incorporation, dating back a minimum of 1 year. Documentation must be provided from an official source in the jurisdiction of your business. To apply as an MSP, please open a ticket or email us at . ### Limitations At this time, a maximum of 30 networks can be onboarded as an MSP. ### Support Users on reseller accounts will not receive support from TCPShield staff. They must consult with the account owner for onboarding/troubleshooting issues. ### Termination In the event an MSP becomes unable to pay their subscription, the MSP will be placed in a 5 day grace period from the day their invoice is marked as overdue. Past this date, their account will be assumed delinquent and reset to free plan. The MSP assumes responsibility that their customers may choose to onboard via their own account in this event. We would be willing to assist of any transfer of ownership for networks that fall into this category via our normal support channels. # Transfer Packets This page covers general usage for transfer packets ### Overview Mojang will soon be adding transfer packets to the game as per Snapshot 24W03A . This guide covers how to get setup so you can start using this feature. Snapshot overview: ### Example {% hint style="info" %} Make sure the IP address of the transfer packet enabled server is public and reachable on its defined port. {% endhint %} **Scenario:** Let's assume we have a sub server "Survival" that lives on 192.168.0.1:5000 and we would like to conceal this address via TCPShield, and we would like to send players to this server via transfer packet. **Step 1:** First, we would add a new backend set for this sub server:

Add transfer packet enabled server as new set

{% embed url="" %} Backend set page {% endembed %} **Step 2:** Now that we have have our backend set defined, we need to create a domain entry that points to it. Go to the domains section and add a new subdomain which points to this new set. We will use "srv05.domain.com" in this example.

Point new domain to transfer packet enabled backend set

**Step 3:** Next, we need to make sure our sub server is configured to accept transfers. In server.properties make sure accept-transfers is true. If they are being transferred to another Velocity or Waterfall instance, this config option will be publicised by their respective teams closer to the major release of 1.21. {% code title="server.properties" %} ``` accept-transfers=true ``` {% endcode %} **Step 4:** Once this record is added, point "srv05" in our case to the protected CNAME shown in the domains section. We have a guide [here](/panel/dns-setup) for DNS setup. ### Transfer packet usage When instructing clients to connect to the sub server, rather than setting 192.168.0.1:5000 as the target server, they should be targeted to srv05.example.com:25565. If DNS is set correctly, all should work as normal. What we have essentially done is added this new sub server as its own protected hostname, where the handshake logic follows the same sequence as if it was any other protected server via our network.