Comment on page
Commonly asked questions

For general information and FAQ
1. Differences between our plugin vs Proxy Protocol
The plugin is essentially a more secure version of Proxy Protocol v2. To those who are unfamiliar, Proxy Protocol provides a convenient way to safely transport connection information such as a client's address across multiple layers of NAT or TCP proxies. In the Minecraft context, this means forwarding player’s IP Address – without it, connections coming to your server will have TCPSheld’s IP Addresses (51.161.19.1 for example).
However, the proxy protocol is inherently unsecured as anyone can spoof proxyV2 header, and that’s where our plugin comes in. The flag (only-allow-proxy-connections) not only transports connection information but also performs a three-way handshake between our proxies and your backend so that your backend knows it's communicating with our proxies.
The flag disables direct connection using backend IPv4 (51.161.19.19:25565 for example) to your server unless the connection is coming from our proxies (you can find the IP ranges at: https://tcpshield.com/v4 and https://tcpshield.com/v4-cf). By extension, this also adds an extra layer of security, as it protects your backend from common attack vectors such as MOTD scanning.
There is a downside: The added security functionality that our plugin has can conflict with other plugins (such as antibot, antiVPN, or Bungeecord’s fork with their own L7 mitigation), which leads to incompatibility. Therefore, sometimes (albeit not recommended), you can disable the flag so that your existing plugins can work with TCPShield. Rest assured, even without the plugin installed, you are still protected from DDoS attacks – as the plugin doesn’t interfere with mitigation capacity whatsoever.
Q: If the plugin is not compatible with what I have on my server, 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 within most Bungeecord and other proxy servers such as Velocity.
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 proxy's config. 
Enable proxy-protocol in your backend set on the TCPShield Web panel (picture below).
For customers with eligible TCPShield Bedrock setup: Set enable-proxy-protocol and use-proxy-protocol  to true in your Geyser config (Under Bedrock  and Remote section respectively). 
​
Proxy Protocol toggle can be found on your backend set
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.
3. Some server doesn't use a proxy server (such as Bungeecord or Velocity) but only run a Spigot backend. For users that are still using this type of setup, they will need to use the TCPShield plugin as proxy protocol is not supported on Spigot (and their forks) by default.
​
2. 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). We do not control the speed of the DNS propagation process, so the best advice here is to be patient and wait for it to finish.
​
3. 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.
​
4. Why do I see <127.0.0.1 initial handler has pinged> in the console?
That's because we serve pings from our proxies 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. We combat this by periodically requesting and caching your MOTD with a 1-second expiry, so the vast majority of the time the response is being served from our edge instead of the backend. Since the MOTD is cached on our edge, the IP we pass downstream to you when we need to fetch a new version of your MOTD will be 127.0.0.1
​
5. Why do I see Switzerland 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 section.
FAQ
Features
Last modified 2mo ago