A Proxy for Ultima Online: Shard Connection, Port Restrictions and Scope Selection

The network side of older games is usually easier to understand: there are fewer layers, the protocol is singular and behaviour is predictable. Ultima Online is a good example. The client connects to a login server, is redirected to the address of the shard you select once the account is verified, and the game session continues from there.

This simplicity produces two consequences on the proxy side. The positive one is that the session runs over TCP and can be carried in a tunnel. The difficult one is that the client offers no proxy setting of its own and the connection goes outside the standard web ports — these two details directly determine where the setup is done.

A third topic is the account side: subscription management, store transactions and code redemption are done from the browser over ordinary HTTPS. This traffic should be assessed in a scope entirely separate from the game session.

How do the login server and shard redirection work?

The connection has two stages. The client first connects to a login server and verifies your account details. If verification succeeds, the server returns the list of shards you can play on; when you select a shard, the client opens a new connection to that shard's address and the game session is established there.

From a proxy perspective, the critical detail here is that the second connection goes to a different address than the first. If you wrote a narrow rule covering only the login server's domain, you will get past login but the shard connection falls outside the scope and either exits directly or cannot be established at all. Your rule must include both stages.

Shards are hosted in different geographic regions and your character is tied to a specific shard. In other words, the answer to "which region should I exit from" is not where you are but where your character's shard is located. It makes sense to pick an exit on the shortest path between these two points (proxy locations).

The game's longevity has another practical consequence: the world contains mechanics that require regular logins. Because progress on an account you cannot access for a long time may be affected, it is important to confirm that you can log in before changing your connection path.

How the two stages are reflected in the proxy rule

The two-stage structure makes it easier to think in terms of processes rather than domains when writing rules. If you try to maintain a domain list, your rule ages as shard addresses change; whereas a rule of the form "send all TCP connections opened by this client to the proxy" survives even when addresses change. This is the real reason per-application routing is preferred with game clients.

The same logic works in reverse: if you do not want to route all the traffic the client generates, it is more practical to separate by timing rather than by domain. Completing the update with the proxy disabled and then starting the game with the proxy enabled produces fewer errors than writing complex rules, and keeps the quota side predictable.

The protocol side: the session is TCP, but what about the rest?

Ultima Online's game protocol is built on TCP. That is convenient from a proxy perspective: an HTTP proxy's CONNECT tunnel and SOCKS5's TCP connect method can both carry this traffic. The "UDP doesn't go through the tunnel" problem seen in action games does not apply here for the game session.

But the client does not work alone. Patches and file updates download over HTTP/HTTPS; the account centre and store run through the browser; if a voice chat application is open alongside, it uses UDP. Each of these is a separate scope decision, and none of them is automatically affected by a rule defined for the game client.

The second and less well-known topic is target port restrictions. For security reasons, many proxy servers allow CONNECT requests only to certain target ports; in default configurations that list is often limited to 443 and a few exceptions. If the game client connects to a port outside the standard web ports, the request is refused by the proxy, and the error message the client shows does not explain why.

So ask your provider this question explicitly: which target ports are connections allowed to? If the answer is "only 80 and 443", the game session needs another solution. SOCKS5 is more flexible at this point, because instead of interpreting a port list at the application layer it opens a TCP connection to the requested address — though the provider's own restrictions still apply. To go deeper into the topic, see The difference between HTTP and SOCKS5 and what port numbers tell you If a direct connection is going to be established, NAT comes into play. Your home router translates the internal address into the external one, and this mapping is created when you send a packet outward. The matchmaking server tells each side the other's external address and port; when both sides send packets outward at the same time, the mappings are created and the connection is established. This behavior is called hole punching, and it works when the router's mapping rule is predictable.

The last row of the table is often misunderstood: if an application does not enter the tunnel, this is not a fault but the natural consequence of a protocol difference. The right response is not to force the rule but to leave that component deliberately out of scope.

Set it up on one machine or the whole network?

Because the client has no proxy field, you have to make the scope decision yourself, and there are three options. The narrowest is per-application routing: only the game client's connections go to the proxy, and everything else on the machine exits directly. Diagnosis is easiest here because you have isolated the variable on its own.

The middle option is the operating system-wide setting. Every HTTP client on the machine is affected by it, including the browser, updaters and background services. As scope widens, quota consumption grows and the traffic of an unexpected application also starts going through the proxy.

The broadest option is the router level. A decision here affects every device in the home: phones, the television, the console, guests' devices. Most home routers are also not proxy clients; such a setup usually requires alternative firmware or a separate routing device on the network. For the options, see using a proxy on a router.