Assetto Corsa Proxy Guide: Community Servers, NAT and Coverage

In a racing simulation, network decisions start with a different question than browser work: which request is actually reading the rule you wrote? On the Assetto Corsa side there is no single answer, because the store client that launches the game, the requests that fetch the server list, the downloaded content, and the in-race state stream all run over different stacks.

The sections below cover three topics. Where do server selection and the country your account is tied to diverge? How does the peer-to-peer connection attempt behave alongside NAT type when a proxy exit is added? And at what point is a proxy useless when you want to run a community server on your own machine or on a rented one?

Let us draw one boundary up front: a proxy is a routing decision. Your exit address changes; your account's registered country, store region, the content you own and your in-game identity all stay exactly as they are. And because an extra hop is inserted, total latency increases in most setups.

What happens on the network, step by step, when the game opens?

The first contact is made with the store client that launches the game. Requests such as session validation, ownership checks and the friends list complete before the game window opens, and all of them are encrypted streams over TCP. The address the other side sees at this stage is whichever line you are exiting from at that moment; if you are using a proxy, it is the proxy server's address.

The server list comes in the second stage. The list is fetched with an HTTPS request, but the latency column in the list does not arrive with the list: the client measures those values with its own probes. If the rule only covers part of this, you end up with an inconsistent picture; the list loads, while the numbers beside it reflect the line the probes went out on rather than the route you will actually experience in the race.

The third stage is the content side. Cars, tracks and add-on packages download large volumes in one go; most of your monthly transfer accumulates not from the hours you play but from the days you add new content. The fourth and most sensitive is the race session: position, input and collision state are carried in many small packets per second, and this stream is as sensitive to jitter as it is to latency.

Four streams, four different expectations

In practice this distinction means one thing: a single setting will not fix all four streams at once. What matters for the store and list side is reachability, for content downloads it is bandwidth, and for the race session it is path length and stability. When evaluating a setup, test all four separately: does the store open, does the list populate, is the download speed reasonable, and do you get disconnects in session?

Server list, region preference and the account's registered country

On the Assetto Corsa side, server selection is largely in your hands: you join a server from the list, and where that server sits determines your route. This differs from games with automatic matchmaking; "region selection" here is not a menu setting but a preference about which community server you enter. Joining a distant server and then complaining about latency is usually the result of a choice, not a network fault.

The account side, on the other hand, works independently of the connection. Your store region, payment method and the content sitting in your library are tied to the account; changing your exit IP address does not change them, and attempting to do so is contrary to the relevant platform's terms of service. This page does not describe such a use. The legitimate counterpart of a proxy is different: verifying whether a community server is reachable from another country, using a fixed address when exiting a corporate network, or isolating whether a connection problem belongs to your own line or to the route in between.

Because the store client carries its own network settings, it may not read the same rule as the game itself. The configuration options on the client side and where they affect game traffic are covered separately in the store client proxy settings article. The practical rule is this: a setting made in the client affects download and library requests, and usually does not affect the race session's packets.

When choosing a country, do not let distance on the map be your only criterion. Physical proximity between two countries and the shortness of the network route do not always coincide; an exit in a neighbouring country can route traffic through a distant exchange point. So make the location decision with measurements taken to the same destination from different exits, not with assumptions.

NAT type, hole punching and the effect of an intervening exit

Most home connections sit behind a NAT: your local address is translated to the outside through a single public address. Connections established from outside in are therefore dropped by default, while the return of a stream opened from inside out passes because it finds a match in the translation table. Applications that establish peer-to-peer connections use this behaviour: both sides send packets outward at the same time, reciprocal mappings form in both sides' NATs, and the stream opens. This is called hole punching.

The success of hole punching depends on how the NAT behaves. A strict (symmetric) translation that reassigns the source port for every destination leaves no mapping the other side can predict, and the attempts fail. On lines that use carrier-level shared translation the picture is harder still; the details of that structure are explained in the What is CGNAT article. For the same reason mobile exits, advantageous as they are for browser work, are the most difficult option in scenarios that require peer connections.

A proxy exit adds a second translation layer to this picture. A classic HTTP proxy only carries TCP; CONNECT the tunnel does not accept UDP, so hole punching attempts never enter this tunnel. SOCKS5 on the side of UDP ASSOCIATE there is a method that can carry UDP, but two conditions must be met together: the proxy server must have UDP relaying enabled, and the game client must implement this method. How the method works is explained step by step in the SOCKS5 UDP support article.

In practice most game clients open their own sockets directly and never ask a SOCKS intermediary. The result is this: while menus and list requests go through the tunnel, race packets exit over your regular line. This is expected behaviour, not a fault; the proxy and NAT comparison sums up the conceptual difference between proxy and NAT and illustrates this distinction with examples.

Running your own server: private and community servers

A large part of the Assetto Corsa ecosystem runs on community-operated servers. A league, a group of friends or a community runs its own server; players join it from the list. When you are the party operating the server, your network problem flips completely: you are no longer connecting outward, you are accepting connections from outside.

This is the most common point at which the proxy concept is applied in the wrong place. A classic forward proxy only carries outbound connections that you open; it has no ability to accept a connection coming from the internet towards you. If you are running a server on your home connection, what you need is port forwarding on the router and an externally reachable address. The direction and purpose of the two concepts are covered in the difference between forward proxy and reverse proxy article.

On the port side, the thing to watch is that a single port is not enough: server software usually uses separate ports for the game stream, queries and the admin interface, and some of these are UDP. Read from the documentation which port does what, do not guess; what port numbers do and do not say about the protocol is covered in the proxy port numbers article. Your home line's upstream capacity is also decisive here; even if the download speed is high, the upload side limits the number of participants.

Where you write the rule is where coverage narrows

The sentence "I turned on a proxy" sounds like a single operation, yet where the rule is written directly determines coverage. The operating system setting looks like the broadest option, but not every application reads it; game and store clients that carry their own network stack often do not. A browser profile gives the narrowest coverage and has nothing to do with the game. Per-application routing tools close the gap, but they too have a limit once you go beyond TCP.

On campus and office networks there is a second narrowing: the egress filter. On these networks usually only a few standard ports are open, and the ports game traffic uses may be closed. The symptom is often misleading; the store opens, the list arrives, but the attempt to join a session times out. The whole topic is covered in the access blocks on school and workplace networks article — on these networks, complying with the institution's policy is your responsibility.

The practical way to verify coverage is not to settle for a single test. After writing the rule, check the following in order: can the store client still sign in, does the server list populate, does the download start, and can you join a session? If one of the four changes, coverage is different from what you assumed.