Proxy for Conan Exiles: Where Do You Define the Rule, and What Does It Cover?

The Conan Exiles client does not connect to a single destination. A discovery layer that lists official and private servers, the services that hold character and account data, the in-game store and cosmetic content pages, and the world itself all operate separately. A single proxy rule does not cover all of them at once.

The protocol is not the only thing that determines scope; where you write the rule matters just as much. There is a vast gap between a rule set on a browser profile and one set on the network device, in terms of how many devices and applications it covers.

This page answers two separate questions: which traffic can technically enter a tunnel, and where it makes sense for you to define that tunnel's scope. Confusing the two is the most common reason people think a working setup is broken.

Which endpoints does the client talk to, and over which protocol?

Web-like traffic is the first group: account pages, the in-game storefront, cosmetic content listings and news panels. These travel over HTTPS on TCP. An HTTP proxy carries this traffic through a tunnel it opens with the CONNECT method and never touches the content; it only sees which domain you connect to.

The second group is the world session. Character movement, synchronisation of built structures, combat and weather updates flow continuously. In this kind of traffic, correct data that arrives late is worse than approximate data that arrives on time; that is why games commonly use UDP. UDP does not pass through a CONNECT tunnel.

The third group is discovery and verification: server list queries, version checks and mod compatibility checks. The fourth is content downloads; packages from the mod workshop and game updates travel over TCP and are larger in volume than all the rest combined. You can see what can be covered depending on whether an application offers proxy fields in the applications that support SOCKS5 article.

How much do you cover depending on the layer you write the rule at?

The narrowest scope is the browser profile: only tabs in that profile are routed, and the game client stays outside. One step up is the per-application rule; the process you select exits through the tunnel while the others stay on your normal line. This is the cleanest option for diagnostics, because its side effects are predictable.

The operating system setting covers most applications on the machine — most, not all. Software that uses its own network stack may ignore this setting, and its traffic silently goes out directly. The widest scope is at the router: every device in the house, consoles included, exits by the same path. For a player whose console has no proxy fields, this is the only practical route.

There is one more option in between: define a separate wireless network on the network device and put only certain devices on it. Scope is then limited at device level and the other people in the house are unaffected. To see where the fields sit in the router interface, see using a proxy via the router .

When deciding on scope, do not trust the “more is better” instinct. A wide scope pushes not only the traffic you want into the tunnel but also traffic you never thought about: operating system updates, cloud backups, video streaming. All of it counts against your quota, and none of it relates to the problem you are trying to solve. The right approach is to start with the narrowest scope and step up one level wherever it falls short.

You can scroll the diagram horizontally to inspect it

The columns show relative breadth of scope; the unit is not a measurement but a comparative weight.

The invisible side effects of a rule written on the network device

A wide scope is not free. When the rule is defined on the router, every device exits through the same egress — smart TV, camera, backup software and home automation included. Some of these devices generate small requests continuously and can fill your concurrent connection ceiling without you noticing.

The second side effect is authentication. Many network devices have no username–password fields; the only option is to add your line's public address to the whitelist in the provider panel. On lines with dynamic addresses this method breaks on every reconnect, and the whole household suddenly loses access.

The third side effect is the rollback. A setting that affects the entire home network is one you need to be able to undo quickly when something goes wrong. Take a screenshot of the current settings before you change anything and write down the rollback steps; trying to remember them at midnight is not a plan.

From request to destination: the four stops on the path

Thinking of a request's path as four stops makes it easier to find where the problem occurs. The first stop is the client itself: which protocol does it use, and which destination does it want to reach? The second stop is the local decision: does this request fall within the rule you defined, or will it go out directly?

The third stop is the proxy egress. Authentication happens here, the connection is opened, and the address the request appears to come from is now the egress address. Connection reuse also comes into play here: on pages that generate many small requests, keeping an open connection alive is faster than performing a new handshake every time. The mechanism is covered in keep-alive and connection pooling article.

The fourth stop is the target service. When something goes wrong in this chain, sort the symptom by the stop it belongs to: an authentication error belongs to the third stop, a timeout to the second or third, a content error to the fourth. Naming things correctly is the most productive work you can do before you start experimenting.

The second stop is the one most often missed, because it is silent. A request the rule does not cover throws no error; it simply goes out on your normal line and everything looks like it is working. That is why the only reliable way to verify scope is to read the egress address you expect from an independent source and compare. Any test run without writing down the expectation first will confirm whatever result you see.

The length of the chain is a decision too. The more layers you insert, the more meaningless your measurements become and the harder faults are to isolate. Start with a single egress; do not add layers unless you genuinely need them.

You can scroll the diagram horizontally to inspect it

Naming a fault by the stop it belongs to is the most productive work you can do before you start experimenting.