Commonly asked questions
For general information and FAQ
Last updated
Was this helpful?
For general information and FAQ
Last updated
Was this helpful?
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).
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.
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 ipconfig /flushdns (Windows) , or changing your DNS server to either 1.1.1.1/1.0.0.1 (Cloudflare resolver) or 8.8.8.8/8.8.4.4 (Google's)
Reminder: TCPShield DOES NOT control the speed of the DNS propagation process.
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.
<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. 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.
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.
