Fall Guys and Proxy: Device Setting or Network-Wide Configuration?

The shortcut to understanding Fall Guys' network behaviour is to think of the game not as one application but as three separate conversations. The first is the account and login layer; the second is the storefront, season pass and cosmetics screens; the third is the round itself, that is, the small packets flowing continuously between you and the server. A proxy does not affect these three in the same way.

Because the game is played on consoles, on a handheld and on PC, the configuration question also varies by device. On PC you can write application-based rules; on a console such a setting usually does not exist, and users naturally look to the router. However, seeing a field labelled "proxy" on a router does not mean the device will behave like a proxy client.

The sections below do the following in order: first they clarify the scope decision, then they show which packet lands where, and then they describe the real use case on the store and account side.

Three separate conversations start on the network when the game launches

The moment you launch the game, the first job is authentication. Your account is verified, your inventory and season progress are fetched, and your friends list is loaded. These are short requests carried over HTTPS; their volume is small, but being able to get into the game depends entirely on them. This layer is the kind a proxy rule can cover.

The second job is the storefront and progression screens. The cosmetics store, the season pass page and event announcements behave like web requests in the background and run over TCP, even when opened from inside the game. Because the content here is prepared server-side, the network the client is on can indirectly affect what is displayed.

The third job is the round itself. Jumping, pushing, your position on the platform and elimination information are carried by many small packets per second. This stream is sensitive to latency and packet loss, so transport methods designed to prioritise speed over reliability are used. To make the distinction concrete, try this: with the proxy defined, open your account page in the browser, then enter the game. The former sees your exit address as changed; the latter does not.

What does entering a proxy on the router mean, and what does it not?

The vast majority of home routers do not run a proxy client. If you see a field mentioning "proxy" in the interface, it is usually the setting the management interface will use when going out to the internet, or a PAC file distribution; that is, it concerns the router's own traffic or a suggestion distributed to clients. A mode in which the router redirects the TCP connections of all attached devices to an external proxy is the exception on consumer hardware.

If network-wide scope is genuinely wanted, the common approach is this: a small machine on the local network runs a proxy service, devices are pointed at that machine, and that machine uses the external exit. This is a different architecture from entering a setting on the router, and it brings management overhead. Also, wider scope is not by itself good news: the same rule covers your TV, your update services and your smart home devices as well.

Another route more often encountered on consoles is the HTTP proxy field in the network settings. This field exists on some consoles and affects only that device's web requests; the game's round traffic still goes its own way. The choice between a router and a device setting is a trade-off between scope and ease of diagnosis. Common router scenarios using a proxy via the router article.

Why does scope narrow on consoles and handhelds?

On closed platforms, the ability to write application-based network rules is not made available to the user. Even if there is a proxy field in the system settings, games' own network stacks are not obliged to read that setting. As a result, on a console a proxy in practice covers browser-like requests and some system services; it does not cover the game session.

The consequence for the user is this: do not set up a proxy on a console and expect the game's behaviour to change. What will change is the exit on the device's web layer. If there are multiple devices on the same home network and you want to route only one, the device setting is the right place; if you want to route the whole home network, the price you pay is that tracking which device goes out over which path becomes harder.

If you are trying to play on a campus or workplace network, the problem is usually not a missing proxy but a closed transport door. On these networks, web traffic may be allowed while the UDP streams games use are blocked. The symptom is familiar: menus open, the store loads, but the round does not start. In this case setting up a proxy leaves the menus working as they already were; it does not open the closed door; access restrictions on school and workplace networks explains this distinction with examples.

The transport protocol distinction: where do round packets land?

HTTP and HTTPS proxies stop at the application layer. For HTTPS they open a tunnel using the CONNECT method and carry encrypted bytes through that tunnel; what they carry is TCP. Real-time game streams, on the other hand, use transport methods that do not wait for retransmission in order to keep latency low, and they mostly run over UDP. When these two sentences are placed side by side, the conclusion follows by itself: round packets CONNECT cannot enter the tunnel.

SOCKS5 adds one possibility to this picture. The protocol has a command called UDP ASSOCIATE that gives the client the ability to relay UDP packets through the proxy. However, two conditions must be met at the same time: the proxy server must keep this command enabled and the application must be written to use this path. The second condition is not common in game clients, so in practice the outcome does not change. A comparison of the payloads the two protocols carry difference between HTTP and SOCKS5 the article.

Let us also close off a common misunderstanding here: NAT type and proxies are not the same subject. NAT concerns how the addresses on your local network are translated to the outside and it affects peer connection setup; a proxy determines at which intermediate stop the request is served. Defining a proxy does not fix your NAT behaviour; it usually complicates it. The difference difference between a proxy and NAT article.