What Does a Proxy Cover in RAID: Shadow Legends, and What Does It Not?

Most people who want to put the game behind a proxy are looking for a single setting: one server address, one port, done. The application, however, is not a single piece. From launch it talks to at least five separate endpoints, and they do not all use the same transport method, the same domain or even the same protocol. If your rule's scope reaches only part of those five groups, the result is "working, but incomplete".

The second issue comes from the game's genre. In a turn-based battle, dozens of packets per second are not sent to the server; a turn is started, a result is requested, a response arrives. Compared with real-time shooters, this structure is far more tolerant of an extra stop. On the other hand, because the interface generates a network request on every tap, latency is felt in the menus rather than in combat.

The third point should be clear from the start: a proxy is a routing decision. Your exit address changes; the server region your account was created in, the country of your store account and your device's language setting do not. Every section on this page was written to show you where you stand relative to that boundary.

Which endpoints come into play when the app opens?

The first request goes to the account and session layer. Identity is authenticated here and the client is issued a session token; your exit IP address becomes visible on the server side for the first time at this step. Once the token is issued, your identity travels with the token rather than the address, so even if your connection address changes later, the session remains the same session. The most common misconception during setup begins here: the login screen opening does not mean all traffic is being routed.

The second group is the requests that carry game state. The hero list, campaign progress, siege results and inventory changes go out as separate calls; each is a short-lived, small, encrypted HTTPS request. This group is the most proxy-friendly, because its behaviour is no different from an ordinary web request.

The third group is asset downloads, and in volume it comfortably exceeds the sum of the others. Hero models, interface packages, audio files and seasonal content are pulled from a content delivery network, and that network's domain may differ from the game's main domain. If your rule covers only the main domain, the game opens and you log in, but the download bar either crawls or completes over your normal line. The fourth and fifth groups are the store and telemetry; both use separate domains and are covered separately in the sections below.

Which connection can pass through the tunnel, and which cannot?

A classic HTTP proxy works at the application layer and carries TCP. For HTTPS it opens a tunnel with the CONNECT method; everything passing through that tunnel is TCP. UDP never enters that tunnel. That single sentence removes most of the mistaken expectations around game traffic.

SOCKS5 sits at the transport layer and can carry UDP through a separate method called UDP ASSOCIATE . For that to work, however, both sides must support it: the proxy server must have enabled the method and the game client must be able to speak SOCKS5. The vast majority of mobile game clients offer no SOCKS5 configuration; they read the system-level HTTP proxy setting, or none at all. The method is explained in detail in the SOCKS5 UDP support article; you can review the protocol's general capabilities on the SOCKS5 proxy page.

A third detail is QUIC. A client using HTTP/3 talks over UDP 443 and does not enter the TCP tunnel. In practice the behaviour splits in two: either the connection goes out directly and never sees your proxy rule, or, if the UDP path is closed, the client falls back to TCP and this time the rule applies. In the second case your setup looks like it is "working"; in the first you fall outside the scope without any error at all.

Should the rule be written on the device or at the network egress?

At the device level there are two routes. On mobile you define an HTTP proxy in the wireless network settings; that rule applies only on that network and silently stops applying the moment the device falls back to cellular data. On desktop, a system-wide setting affects all applications, while application-level routing puts only the process you choose into the tunnel. For a step-by-step walkthrough, see Android proxy settings article, are useful.

A rule written at the network egress is a different category. Here you do not configure individual devices; you place a rule at the point where traffic leaves the network, and every device on that network follows it. Most home routers have no direct "proxy server" field for outbound traffic; that capability is provided either by alternative firmware or by a small router machine placed at the network's egress. The general framework of the approach is using a proxy via the router article.

The choice is as much about what happens when something breaks as about how many devices are covered. If a device setting breaks, only that device is affected and removing the setting takes ten seconds. If the rule at the network egress breaks, everything in the house is affected at once: the television, the smart plug, the work computer. That is why the rollback path for a network-level setup must be written down before the setup.

• Take a screenshot of the current setting before you write the rule.
• Leave a wired fallback path for the rule at the network egress.
• Remember that on a mobile device the setting covers only that wireless network.
• When testing scope, try the browser first rather than the game.

The scope of a setup at the network egress and the price it pays

The biggest advantage of a network-level setup is that whether the client reads the system proxy setting no longer matters. Because traffic is already routed as it leaves the network, no cooperation from the application is required. On mobile game clients, this removes the point at which the device setting most often fails.

The price falls under three headings. The first is authentication: many configurations at the network egress do not support sending a username and password, so you switch to IP authorisation on the provider side. If your home line gets a dynamic address, your authorisation list goes stale every time the line renews and the entire network is unable to get out at once. A comparison of the methods is proxy authentication methods article.

The second is the difficulty of separation. When the whole network goes through a single exit, your game traffic, your work meetings, your streaming services and your update downloads all consume the same quota. On a plan billed by data transferred, this grows the bill far faster than the game's own share. The third is the cost of diagnosis: when a problem arises, you have to remove the rule first to determine whether the fault lies in the game, the rule or the provider — and the whole network changes while you do it.