Proxies for Rise of Kingdoms: Measurement, Latency and Limits

This game's network profile sits at an interesting midpoint. There are units constantly moving across the map and live events, but none of it requires frame-by-frame synchronisation the way shooters do. When a march order is given, the client declares an intent to the server, the server returns the result, and the interface animates it. The few tens of milliseconds in between do not change the fairness of the gameplay.

Connection quality, on the other hand, is felt. A dropped connection, alliance chat freezing, or an event screen failing to load all show up directly in the game experience. The problem starts here: the user says "bad connection", but there is no measurement to say what exactly is bad. Is latency high, is there loss, or is just a single endpoint failing to respond?

The sections below take up that question in order. First, which traffic can pass through a tunnel; then how to take the measurement; then how to read the result; and finally, in which cases the proxy decision is genuinely meaningful.

What can the tunnel carry, and what can it not?

The CONNECT tunnel opened by an HTTP proxy carries TCP. Account sign-in, map state calls, alliance lists, event screens and store pages all fall into this class; each is an encrypted TCP session and passes through the tunnel without trouble. That means most of the screens you see in the game.

What stays outside the tunnel are the streams carrying UDP. Voice chat, some real-time notification channels and content requests using HTTP/3 are in this group. SOCKS5's UDP ASSOCIATE method can carry them in theory, but three conditions must be met at once: the proxy server must have the method enabled, the client must be able to speak SOCKS5, and the network in between must allow that association. Setups where all three are met are not common on mobile game clients.

This distinction has great diagnostic value. If only a function that carries UDP is breaking, the problem is outside the proxy's scope and changing the proxy setting there changes nothing. Conversely, if the sign-in and menu screens are stuttering, the problem is on the TCP side and the rule is directly relevant. For the general framework of protocol choice, see proxy protocol selection guide is a good starting point.

A third detail is where domain resolution happens. When using an HTTP proxy, the client declares the destination in the form CONNECT server.example:443 and the proxy handles resolution. SOCKS5, on the other hand, accepts the destination both as a plain IP and as a domain name; since the client's own setting decides which is sent, where resolution happens is a result of the configuration rather than the protocol. When resolution is done on your network, the destination domains are visible to your local server; moreover, a content node close to you is selected while the connection is established from another country, and the path lengthens unnecessarily. Knowing this distinction when measuring explains why the same exit gives different results on two different clients.

Which tool should you measure packet loss with?

The most common mistake is deciding on the basis of a single measurement tool. Three different tools answer three different questions and are not interchangeable. A simple echo test tells you how long an address takes to answer you and how many packets were lost. A route tracing tool shows which nodes the packets pass through. A continuously running monitoring tool reveals whether the problem is time-dependent.

Measurement has three rules. The first is duration: a ten-packet test cannot catch a problem that occurs intermittently over minutes; measure over at least a few hundred packets. The second is repetition: run the same test at different times of day, because on shared lines there is a real difference between evening and morning hours. The third is comparison: without running the same test with the proxy on and off, you cannot know the effect of the extra hop.

To test your own exit, ping test and proxy checker tool gives a quick first look; these measure not the game's server but the reachability and responsiveness of the exit you use. A fuller account of the method is in how to test proxy speed article.

Reading the measurement result correctly

One of the intermediate nodes failing to respond in route trace output does not mean there is loss there. Much network equipment treats control packets addressed to it as low priority or does not answer them at all; yet it forwards the traffic passing through it in full. The rule for reading is simple: what matters is the result on the last line, not the percentages on the intermediate lines. If there is no loss at the endpoint, the asterisks in between are usually noise.

The second common misconception is leaving Wi-Fi out of the equation. A significant share of loss arises on the home Wi-Fi connection, from sharing a channel with neighbouring networks or from the device being far from the router. To isolate this, repeat the measurement once over a wired connection; if the loss disappears, what you are looking for is not a proxy but a Wi-Fi rearrangement.

The third is choosing a solution without knowing where the loss occurs. A proxy does not eliminate loss occurring on your access line; you still send the traffic over the same line, and you have added one more hop on top. The only kind of loss where a proxy can be meaningful is loss that occurs only on a particular path and that can be avoided by using a different exit. And only comparative measurement will show that.

So that latency and loss are not confused with one another, what proxy latency is defines the two metrics separately. Why variability is higher on mobile lines is covered in mobile proxy speed and latency article.

The extra hop's contribution to total time

The total time of a request is not made up of a single piece. The local segment from your device to the router, the segment carried by your access line, transport across the backbone and the server's processing time all stack up to form the total. When you use a proxy, two new pieces are added to this chain: the distance between you and the proxy, and the distance between the proxy and the destination.

The natural result is that total time lengthens in most setups. A proxy does not lower your ping; on the contrary, it adds a hop. Marketing narratives that reverse this sentence are not technically correct. The only exception is where your default route is unnecessarily long and the proxy sits on a backbone that connects more directly to the destination; this is not a rule but an exception that cannot be assumed without measurement. The discussion of the subject is in does a proxy lower game ping the article.

The practical decision is this: if your aim is to improve response time, a proxy is the wrong tool and you should first fix the variables on your own line. If your aim is to go out from a fixed address, pass through a corporate network, or verify how a piece of content appears in another region, a proxy is the right tool and you factor in the latency it adds as an acceptable cost.

The number of concurrent connections is another variable affecting the overall experience. If more than one device or more than one application goes through the same exit, the ceiling fills faster than expected and the result appears to the user as "slowdown"; the details are in concurrent connection limit the article.