Commonly asked questions
For general information and FAQ
The plugin is essentially a more secured 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 player’s IP addresses straight to you. Your server will no longer need the TCPShield plugin to extract 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(orhaproxy-protocolif you are using Velocity) in your proxy's config. - Enable
proxy-protocolin your backend set on the TCPShield Web panel (picture below). - For customers with eligible TCPShield Bedrock setup: Set
enable-proxy-protocolanduse-proxy-protocoltotruein your Geyser config (UnderBedrockandRemotesection respectively).
Proxy Protocol toggle can be found on your backend set
Note: This approach does not validate connections are coming from us like 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 greater effect.3. Some server doesn't use proxy server (such as Bungeecord, Velocity) but only running barebone 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). 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.
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.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 requesting your MOTD, forcing your server to response and sending 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 request and cache your MOTD with a 1 second expiry, so vast majority of the time the response is being served from our edge instead of backend. Since the MOTD is cache 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.1Last modified 3mo ago