(Some other hosts call this "anycast", but it's not true anycast. We also have a different write-up on its nature and limitations.)
Why would I choose this option?
There are two main reasons for choosing Proxied Chicago as a location:
- Your server is seeing many spoofed A2S_INFO query attacks that are not being effectively mitigated. This is something that you might know if you see messages in your Events log and talk to us about it. We may recommend moving to this location as one mitigation option.
- You want to make your server appear to be lower-latency in the client game browser / favorites list than it really is. This can help drive traffic to the server. If your competition is doing something similar at another host, this could be seen as a way of fighting back.
The Proxied Chicago location is currently only available for specific types of standard game servers in our managed/standalone system. It is not available to unmanaged services.
Managed (VDS/dedicated machine) customers must have a service in Chicago and are currently limited to two Proxied Chicago game servers per host, as we continue to test this offering and gauge demand.
How can this help with (D)DoS attacks?
Each edge node of the proxy system queries the real game server at intervals, recording responses to A2S_INFO and A2S_PLAYER queries. When a player's server browser makes the same type of query later, its request is intercepted and it receives a response from the network edge, instead of from the game server. Because the game server never sees the request, it doesn't have to spend CPU, memory, or network resources on handling it.
Some attackers will send large numbers of spoofed A2S_INFO requests to the server in order to bog it down, with fake sources. With the proxy system, most of these will end up being answered by a single edge node, very efficiently, and the server itself will be unaffected.
How can this help with apparent latencies?
Ordinarily, a query would have to go to Chicago and the response would come back from Chicago. Since latency (ping/RTT) is mostly determined by distance, a client who is far from Chicago may see a high latency.
With cached responses served from our network edge, many clients will funnel through a different location than Chicago that is closer to them, receiving a response from there instead. This response will take less time, making the server appear to have a lower latency. (The response also might be faster than a game server would respond, even if were at that closer location, due to its internal delays.)
If a player then connects to the server, that person will be able to play normally, with a latency that is closer to what the client would normally see to Chicago.
As a more specific example, imagine that a client is located in Phoenix. That client might normally have a 40ms latency to Chicago. But, with the proxy set up, the client's ISP might see our advertisement from Los Angeles, possibly just 10ms away. The client's browser queries the server and gets a response from LA, and the server looks much better. When the client connects, the client will continue to be routed through LA, and up to Chicago on our own network, so the real in-game latency might end up being 50ms.
Can this improve performance?
In some cases, it may improve performance. If a client lives near an edge node city, and the client is proxied through that city, then it's possible that our own path to Chicago may be faster than the client ISP's would have been, giving a lower latency in-game.
For instance, in one case we saw, the client lived in Seattle and normally had a latency of 60ms to Chicago. With the Proxied location, the client came onto our network in Seattle; our internal path to Chicago was faster than the ISP's, giving an overall in-game latency of 53ms for the client. (Meanwhile, outside the game, the client saw the server as 10ms, since the query response came from Seattle.)
In some other cases, the performance may be similar or may be lower. For instance, if an ISP uses a transit provider that isn't available from us in the closest location to the ISP, but that we use elsewhere, it could lead to a more scenic path through a distant city.
How will this impact other types of (D)DoS attacks?
Proxied Chicago will handle distributed attacks that involve easy-to-filter traffic well. For instance, reflection/amplification attacks, or those from distributed botnets whose bots are already blocked by us.
Most other attacks will also be properly handled with our standard mitigation system, at each separate location.
Proxied servers can't handle spoofed attacks that can't readily be filtered, or some other application-specific attacks. These attacks might get through to the game server and cause problems. But, those types of attacks would hurt regular game servers in the same way.
Are there downsides to using Proxied Chicago?
- Overall, players are likely to have slightly higher latencies in-game, though that is not certain. (Some groups of players may see lower latencies, as discussed above.)
- Since the proxy setup is dependent on every location being online and tunnels between them working properly, it introduces some additional factors that can make troubleshooting routing problems more difficult.
- Valve may choose to stop allowing proxied queries/"anycast" responses/latency cheating. This would be easy for them to do by simply blacklisting /24s that are seen using the technique. However, Valve has intentionally turned a blind eye to this behavior for years and seems to approve of it, so that is not likely.
In the other FAQ entry, NFO says that this type of "anycast" (TMN) has serious drawbacks. Why is it being offered as an option now?
For certain games, all of the most popular servers are now proxied and use cached query responses. This has led to high demand from customers. (Valve allowing it has also surprised us, as we thought that Valve would have stopped it.)
We have weighed that demand against the drawbacks that we cover including latency, DDoS resistance, and complexity.
- In terms of latency, this comes down to customer choice and preferences. For some customers, it may make sense to trade off lower in-game performance for cached responses.
- In terms of DDoS resistance, we significantly upgraded our locations in 2024 so that they can better handle DDoS traffic, so there are no significant weak links, and this is less of a concern for us. Still, we will be carefully monitoring this system. If anything causes us to shut the proxied location program down, it would be this.
- In terms of complexity, we have the brainpower and resources to do this right. We have been using tunneling internally for many years now, as well.
Overall, we think that it makes sense to test this as an option.