Advanced Configuration
DNS, multiplexing, TLS fragmentation, the kill switch and WARP — what each option does, its default, and when changing it is actually the right move.
Advanced Configuration
Everything on this page is off or conservative by default, and most of it should stay that way. These are settings for a specific symptom, not a checklist to work through — several of them make things worse when enabled without cause.
Defaults are from the iOS and macOS clients. Other platforms expose the same concepts with a narrower set of switches.
DNS
| Setting | Default |
|---|---|
| Remote DNS | https://1.1.1.1/dns-query |
| Direct DNS | https://223.5.5.5/dns-query |
| Domain strategy | Auto (both) |
| Fake DNS | Off |
Two resolvers, because two kinds of name need answering. Remote DNS resolves names for traffic going through a node — it is queried through the tunnel, so the answer reflects the node's vantage point and your local network never sees the query. Direct DNS resolves names for traffic that bypasses the tunnel, and is queried directly.
Both defaults are DNS-over-HTTPS, so queries are encrypted rather than visible to anything between you and the resolver.
Domain strategy decides whether a name is resolved to IPv4, IPv6 or either.
auto follows the connection. Force it only when a destination is reachable on
one family and not the other.
Fake DNS hands out placeholder addresses immediately and resolves the real one when the connection is made. It removes a round trip and keeps the real lookup off your local network entirely. It also confuses anything that expects a DNS answer to be a genuine address — some VPN-detection, some local tooling. Off by default for that reason.
Multiplexing
| Setting | Default | Options |
|---|---|---|
| Mux | Off | smux, yamux, h2mux |
Multiplexing carries several logical connections inside one transport connection. It reduces handshake overhead when an application opens many short connections — a page with dozens of small requests is the classic case.
It is off by default, and that is usually correct:
- The node has to support the same mux protocol. A mismatch fails in ways that look like a broken node.
- One transport connection becomes a shared fate. A stall affects everything inside it rather than one request.
- For a few long-lived connections — a download, a video stream — it adds nothing and can cost throughput.
Turn it on if many-small-requests latency is your actual complaint, and turn it off again if anything gets stranger.
TLS fragmentation and padding
| Setting | Default |
|---|---|
| TLS fragment | Off |
| Fragment packets | tlshello |
| Fragment size | 10-100 |
| Fragment delay | 50-200 |
| Mixed SNI case | Off |
| TLS padding | Off |
| TLS padding size | 100-200 |
These change the shape of the first packets of a TLS connection. They exist for one situation: a network that inspects the TLS handshake and interferes based on what it sees there.
- TLS fragment splits the client hello across several packets, with the size and delay ranges above, so the server name is not sitting in one readable packet.
- Mixed SNI case varies the capitalisation of the server name. Case is insignificant to a real server and significant to a naive string match.
- TLS padding adds filler so the handshake does not have a characteristic length.
Every one of these costs latency on every connection and none of them helps on a network that is not interfering. Enable them when a specific destination fails in a specific way — not preventively.
Kill switch
| Setting | Default |
|---|---|
| Kill switch | Off |
When on, traffic is blocked if the tunnel drops, rather than silently falling back to your ordinary connection. The point is to make a failure loud: without it, a dropped tunnel means your traffic continues over the default route and nothing tells you.
Turn it on if traffic leaving the tunnel is a problem for you. Expect the trade-off — when the tunnel is down, you have no network at all, which is exactly what you asked for and still surprising the first time.
WARP
| Setting | Default |
|---|---|
| Enable WARP | Off |
| Detour mode | — |
WARP is Cloudflare's network. AI Booster can use it as an additional hop, in either order:
- Proxy over WARP — your traffic reaches WARP first, then the node. The node sees a Cloudflare address rather than yours.
- WARP over proxy — traffic reaches the node first, then WARP. The destination sees a Cloudflare address rather than the node's.
Which you want depends on which side you are trying to change the apparent origin of. Neither is faster; both add a hop.
A licence key and account fields are available for a WARP+ subscription. Left empty, the free tier is used.
Alternate core
| Setting | Default |
|---|---|
| Use Xray core | Off |
Switches the underlying engine. Protocol support and behaviour differ between cores, so a profile that works on one may not work identically on the other. Only relevant if you have a profile that specifically requires it.
A note on changing several at once
The common failure here is enabling four options while chasing one symptom, and then not knowing which one helped — or which one caused the new problem.
Change one. Test. Change it back if it did not help. The defaults on this page are conservative because most of these settings are the right answer only for a narrow condition, and actively harmful outside it.
See also
- Proxy settings — service modes, ports, TUN
- Troubleshooting