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 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 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.
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):
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.
If you are unable to create a Bedrock CNAME, open a ticket and ask to be moved to an IP without a tunnel. This is a very simple request for us to carry out.
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)
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 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.
