Shadowrocket
Rules and Configuration Guide

01 Configuration Structure and Scope

In Shadowrocket, connection details and traffic-routing rules serve different purposes. Connection details explain how to connect to a server you already have and typically include the protocol, address, port, and authentication fields. Rules determine which policy to apply to a request. Importing a Subscribe does not select a rule file, and importing a .conf file does not provide a server. Before editing, check the SERVER list in Home and the file currently selected in Config. These are separate parts of the app, not two views of the same data.

Start with the Four Sections

Configuration files use bracketed section names to define the scope of their contents. [General] holds global parameters, [Rule] contains ordered matching rules, [Host] defines hostname mappings, and [URL Rewrite] contains URL rewrite expressions. These names are not headings for people to read; they tell the parser how to interpret what follows. The same line may mean something different in another section—or be invalid altogether. When copying a snippet, check its section as well as its contents.

[General]
bypass-system = true

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

This snippet illustrates section boundaries; it is not a complete configuration to enable as-is. example.com and the documentation address are syntax examples. Actual requests still depend on your server, selected policy, and network conditions. In particular, [Host] and [URL Rewrite] can change resolution or request targets. When establishing a baseline, leave out specific entries in these sections and add them one at a time after the basic connection is stable.

A file existing does not mean its rules are active

Config can store multiple files, so when troubleshooting, identify which one is actually in use. After saving edits, return to the file list and check the selection, then go to Home and verify Global Routing. Config is the usual starting point for checking rule-based routing. Proxy and Direct are separate global routing modes. A saved file alone does not mean every request is being evaluated against its rules.

Keep a working copy before editing, and give it a name that makes its purpose easy to recognize, such as “Domain rule test.” Never put server passwords, subscription tokens, or personal account details in a filename. If you maintain both a remote file and a local copy, confirm which one you are editing. A remote update may overwrite local changes; keep important customizations in a separate record rather than relying on memory to recreate them.

Make Changes in Small, Testable Steps

Ideally, change only one layer at a time. If you need to change how a domain is routed, edit just the relevant [Rule] line; do not also change DNS, Host, and server authentication fields. Then, if the result changes, you can trace it to the rule you just edited. When several layers change before testing, even a successful result does not reveal which change worked, making future updates harder to maintain.

When reviewing a file, find the section names first, then locate FINAL and check which broad rules precede the fallback. This gives you a faster overview than reading every line from the beginning. If a parameter is unfamiliar, keep its current value until you know whether it controls traffic handling, name resolution, or request matching. Do not guess based on the field name or copy a similarly named field from another configuration format into .conf.

02 General: Global Settings and DNS

Parameters in [General] affect the runtime environment for the whole configuration; they do not make decisions for individual domains. If a rule is written correctly but behaves unexpectedly, check whether global settings are changing how traffic enters the rule system. In particular, distinguish how system traffic is handled, how a hostname is resolved to an address, and which route a connection ultimately uses. These are related, but they are not the same setting.

bypass-system and skip-proxy

bypass-system = true lets certain system traffic bypass proxy handling through the relevant mechanism. It does not enable every DIRECT entry in [Rule], nor does it mean the entire device is using a direct connection. To determine whether traffic is subject to rule matching, check actual request records and current interception conditions rather than inferring behavior from this Boolean value alone.

[General]
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16
dns-server = system

skip-proxy specifies address ranges that should bypass the relevant proxy handling. This example includes loopback and one common private subnet, but it does not cover every home or office network. If a router, printer, or local service uses another range, check its actual address. Adding every private address range at once may change how internal services that need a controlled route are accessed. First identify the network and devices involved.

Bypass here and DIRECT in [Rule] are not interchangeable. The former may affect whether traffic enters later processing; the latter selects a direct policy at the rule level. If a local-network request never appears in the request records, first check whether it was bypassed globally. Changing the rule's position usually cannot affect handling that was decided earlier.

Check DNS Results and Routing Separately

dns-server = system uses the corresponding system resolver. It is a useful baseline, but it does not guarantee that every network can resolve the names you need. DNS converts hostnames to addresses; PROXY and DIRECT determine the connection route. A domain rule matching PROXY does not by itself confirm that the expected resolver was used, and successful resolution does not prove that a connection to the target port can be established.

When configuring another resolver, use an address only if you understand its purpose, permissions, and reachability. Avoid stacking multiple resolvers just to make one test pass: varying results, caches, and network changes can make the problem hard to reproduce. Record the system resolver's result first, then compare other settings without changing routing rules. This helps determine whether the problem is actually in the resolution layer.

Address Rules May Trigger Resolution

Domain conditions can usually match the hostname in a request directly. GEOIP and IP-CIDR conditions, however, need the target address. If a request initially contains only a domain name, the client may need to resolve it to evaluate an address rule. The no-resolve option on a rule means not to resolve a domain solely for that rule; it does not mean DNS is no longer needed for the connection as a whole. This distinction affects whether a domain request can match an address-based rule.

Requests that already have an address and requests with an unresolved hostname may follow different matching paths, even when they access the same service. If you use no-resolve, document why—for example, to avoid an additional resolution during rule evaluation. Do not add it automatically to every IP rule. If the policy depends on the final address, account for and verify the resolution requirement.

Recheck After a Network Change

After switching Wi-Fi networks on iPad or iPhone, first confirm that the basic connection works, then check resolution and local-network reachability again. The same private address may refer to different devices on different networks, so a previously successful result is not a permanent guarantee. On Demand controls when a connection starts; it does not replace checks of DNS or [Rule]. After the connection starts automatically, check the policy applied to new requests.

Keep the number of global settings aligned with what you need them to do. If one specific domain rule solves the problem, there is no need to change every resolution path. If adjusting one private subnet is enough, do not expand the entire bypass list. Before saving, check commas, equals signs, and address prefixes. Then test with a new request so an existing connection or cache does not mask the change.

03 Rule: Domain Conditions and Matching Scope

A typical [Rule] line has three fields: rule type, match value, and target policy, separated by English commas. The domain field takes a hostname, not a protocol, path, or port. To route requests for example.com, enter the hostname—not a full web address. Domain rules match a request's target name, not a page title, page content, or every piece of text in the address bar.

DOMAIN: Match an Exact Hostname

DOMAIN,example.com,DIRECT matches only the exact hostname example.com. It will not match a different name just because that name contains the same text, and it does not automatically include api.example.com. DOMAIN has a clear scope when you want to set a policy for a specific API or login hostname, and it typically belongs before a broader suffix rule.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

In this example, api.example.com matches the first line and uses DIRECT. example.com and other matching subdomains continue to the second line and use PROXY. If the first two lines are swapped, the broader suffix condition matches first and the exact exception no longer applies. The rule system does not automatically move a more specific DOMAIN rule to the top; line order is an important part of how requests are evaluated.

DOMAIN-SUFFIX: Match a Domain and Its Subdomains

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, such as a.example.com and b.a.example.com. The suffix is evaluated at domain-label boundaries, so notexample.com is not considered part of the same domain. A common mistake is to add an asterisk, assuming a wildcard is required. For this rule type, enter the domain suffix directly; there is no need to turn it into a regular expression.

A suffix rule works when an entire domain family should use the same policy, but a site's full functionality may depend on other independent domains. Login, images, files, and analytics may use different domains. So if the homepage loads but attachments do not, that does not necessarily mean the suffix rule failed. Check the actual hostname of the failed resource before deciding whether a separate rule is needed.

DOMAIN-KEYWORD: Match Text Within a Hostname

DOMAIN-KEYWORD,example,DIRECT matches requests whose domain contains the text example. Its scope is harder to predict than a single suffix and may include hostnames belonging to unrelated organizations, while missing related resources with different names. Unless you specifically need this broad condition, prefer an exact hostname or suffix rule to reduce unexpected matches that are hard to explain later.

Use Request Records to Identify Match Conditions

Before adding a rule, identify the actual request hostname instead of guessing from a page or service name. An app may connect to several backend services, and the domain shown in the address bar may be just an entry point. Reproduce the failed action and find the target name in the records for that time. Then choose DOMAIN or DOMAIN-SUFFIX. If the record shows only a target address, do not invent a hostname condition.

For internationalized domain names, the displayed name may differ from the encoded form used on the network. Use the hostname shown in the client records as the basis for checking a match. When copying an address, remove any path, query string, or accidental whitespace. Domain rules do not work like URL Rewrite; putting a path in the DOMAIN field does not enable path matching.

When maintaining multiple domain rules, keep the business purpose separate from the syntactic scope. For example, the goal might be to route a test service you own through a particular path, but the condition should name the specific host. A note like “work website” will not explain months later why a broad keyword was used. Keeping match evidence and the reason for each choice is usually more useful than adding overlapping rules.

04 IP, GEOIP, and USER-AGENT Conditions

Domain conditions use hostnames; address conditions use the connection's target IP. They refer to different things. A domain does not necessarily map to a fixed address, and an address does not necessarily serve only one domain. Content delivery, load balancing, and network location can all affect resolution. Use IP rules as the primary matching method only when the target is actually managed by address range.

IP-CIDR: Addresses and Prefix Lengths

IP-CIDR,192.168.0.0/16,DIRECT matches an IPv4 address range. The number after the slash is the network prefix length, not a port or an address count. Longer prefixes generally cover smaller ranges; a single IPv4 address can be represented as /32. Before editing, confirm which subnet the target belongs to. Do not expand the range just because several addresses start with the same digits.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

192.0.2.10 and 2001:db8::/32 are documentation examples, not real services to connect to. IP-CIDR6 is for IPv6 address conditions; putting an IPv6 address in an IPv4 rule does not convert it automatically. If a service returns both address types, checking only IPv4 rules may miss a connection made over IPv6. Check the address family in the request records before deciding which rule is needed.

Local Network Rules and Network Topology

Private addresses are common on home and office networks, but their assignment depends on how each network is managed. If a printer is unreachable, check its actual address, subnet, and network isolation settings first. If it is on a separate isolated network, choosing DIRECT will not create a route between subnets or grant access. Rules select an existing path; they cannot create a missing network connection through the router.

For address rules with no-resolve, check whether the request already has a target address. If it is still a hostname when evaluated, the option may prevent the rule from resolving it to obtain the address it needs. Choose whether to keep no-resolve, add a specific domain rule, or test behavior with resolution enabled based on your goal. Do not blindly copy the same subnet into several rules.

GEOIP: Match by IP Geolocation Database

GEOIP,CN,DIRECT matches according to the geographic classification of the target IP; CN is a region code. It does not identify the language of a page, the user's location, where a site is registered, or the region a service targets. A Chinese-language page may use addresses in different regions, and an international service may resolve to a local delivery address. Do not treat GEOIP as a way to identify a service's business identity.

Database classifications have limits and can change; a match today is not a permanent conclusion. To handle a specific service consistently, put its domain exception before GEOIP. Use GEOIP afterward if you need to classify remaining addresses broadly. If the result differs from what you expect, record the target IP and resolution result, then check the database and rule order rather than assuming the server protocol is at fault.

USER-AGENT: Limits of Request Information

USER-AGENT matches information in a request's User-Agent field. For example, USER-AGENT,ExampleClient*,DIRECT specifies a prefix pattern. It does not identify every connection by the app's displayed name or act as a system-level app identifier. This condition can only work when the client can access the relevant request information, the request includes the field, and its value matches a supported pattern.

HTTP fields in encrypted connections usually cannot be read from the outer connection alone. Do not assume USER-AGENT can reliably match every HTTPS request, or broaden certificate trust or decryption just to make this rule match. The basic setup in this guide does not rely on those steps. If an explicit domain condition will do, start with that easier-to-verify option.

When combining these rule types, first ask what information is actually visible: a hostname, IPv4 address, IPv6 address, or readable request field. A rule cannot reliably match data that is unavailable, even if its syntax is correct. Checking information visibility separately from matching syntax helps avoid repeatedly changing a rule that has nothing to match against.

05 PROXY, DIRECT, REJECT, and Rule Order

The first fields of a rule describe the request; the final policy field describes how to handle it. PROXY, DIRECT, and REJECT are the basic policy keywords used on this page; keep them in English. PROXY uses the applicable proxy route, DIRECT connects directly, and REJECT blocks a matching request. These are not latency ratings and do not switch automatically based on the result of a connection.

A Policy Does Not Replace Server Settings

PROXY requires valid details for a server you already have and the appropriate selection state. A rule can match PROXY and still fail if the authentication, port, or protocol settings are wrong. DIRECT also depends on the underlying network being able to reach the target; it does not guarantee success. REJECT deliberately blocks a request. Before using it for a key endpoint, confirm what depends on that endpoint, since blocking it may affect login, syncing, or content loading.

The first matching rule determines the policy

With the usual top-to-bottom matching order in [Rule], each request is evaluated from the first line onward, and the first matching rule determines its policy. A later rule does not override the result just because it is more specific. Priority comes first from position, not from a rule name that sounds more technical or a longer field. Put specific exceptions before broad conditions so the file order makes each decision easy to explain.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

api.example.com uses DIRECT; blocked.example.com is blocked with REJECT; other names matching the example.com suffix use PROXY. Only if none of these domain conditions match does evaluation continue to the private subnet and GEOIP rules. Even if an example.com domain resolves to an IP in CN, the earlier suffix rule has already set its policy. The later GEOIP rule does not change it to DIRECT.

FINAL Is a Fallback, Not a Patch

FINAL has no domain or address condition. Common forms include FINAL,PROXY and FINAL,DIRECT; place it where it can serve as a fallback. If FINAL appears too early, later ordinary rules will not get a chance to match. Keep one clearly defined final policy and document why you chose it. Multiple FINAL lines pointing in different directions do not complement one another.

Both fallback choices have clear prerequisites. FINAL,DIRECT sends traffic without a specific rule to a direct connection; FINAL,PROXY sends it through the proxy route. Choose based on your existing server, the traffic involved, and the impact of failures—not because one option is universally correct. Before changing the fallback, test the services you use and confirm which traffic will change routes.

Distinguish Routing Modes from Rule Policies

Config, Proxy, and Direct in Global Routing are app modes; PROXY and DIRECT in rules are configuration keywords. The wording is related, but they are not interchangeable configuration fields. To test rules, switch back to Config. After temporarily selecting Proxy or Direct for comparison, make a note of whether to restore Config. Otherwise, your next test may still be using a global mode, making it seem as if a rule has changed.

Keep REJECT tests tightly scoped. Start with one test hostname you can identify and confirm its match in the records before considering a suffix. Do not block a large number of requests with a broad keyword and judge the result by whether a page seems faster. Important resources may be used later for syncing, payment confirmation, or session refresh; a short period of normal-looking behavior does not prove all dependencies have been tested.

06 Host and URL Rewrite: Mapping and Rewriting

[Host] and [URL Rewrite] can both affect what happens when you access a site, but they operate at different layers. Host maps names to addresses; URL Rewrite changes or redirects matching URLs; [Rule] determines which policy a request uses. Keeping these layers separate helps explain changes in the destination, certificate errors, or why a routing condition did not match as expected.

Host: Set an Address for a Hostname

example.com = 192.0.2.10 assigns an address to that hostname. It does not change the domain in the address bar to this IP or automatically change the HTTP Host, the service name used for TLS, or the remote certificate. The server still needs to handle the original hostname correctly. If you enter a reachable IP but the other end does not serve that domain, you may see an incorrect page or a certificate mismatch warning.

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.11

The two mappings in this example are independent; a root-domain entry does not automatically cover every subdomain. If you need to pin multiple hostnames, check the target and purpose of each one. Use addresses from an environment you can manage and verify. Pinning an old address for a public service that changes frequently may disrupt load balancing and failover that would otherwise work normally.

Host is useful for your own test environment or a specific, well-understood resolution fix—not for probing an unknown address. To troubleshoot, first remove or disable the mapping in your working copy and compare the result with normal system resolution. If the connection works again, check whether the mapping target is outdated, the port is open, and the certificate name is correct. Do not respond by adding more proxy rules.

URL Rewrite: Limit the Scope of Changes

A typical URL Rewrite expression includes a match pattern, replacement target, and handling method. The example below shows how to redirect an HTTP URL for example.com to its HTTPS equivalent. It illustrates syntax only. Before using a rule, confirm that the target supports HTTPS and that the redirect will not conflict with the server's own behavior. Test a real service address on a single entry in a working copy first.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

The dot in the matching expression is written as \. to match a literal period. If you write example.com directly, the dot in the regular expression can match any character and broaden the rule. The opening ^ anchors the match to the start of the string, and the slash after the domain helps constrain the hostname boundary. Make rewrite rules as specific as possible instead of using a broad expression across all requests.

Rewriting Does Not Provide General Access to Encrypted Content

Whether the client can read a complete URL depends on the request type and information available. The path in an HTTPS request is usually encrypted, so do not assume URL Rewrite can match any HTTPS path. The visible connection target is not the same as the full HTTP request. If you only need to change the connection policy, use domain or address conditions in [Rule] instead of adding request-content handling.

This guide does not use expanded certificate trust or decryption as a basic configuration step. Before enabling a feature that requires additional request visibility, understand its permission boundaries and intended use, then check the in-app instructions. Do not add a certificate from an unknown source to fix an ordinary connection failure, or mistake a service authentication failure for a limitation of URL Rewrite.

Redirect Loops and Duplicate Conditions

A redirect loop can occur when one rule changes URL A to B and another rule or the server changes B back to A. If a browser keeps redirecting or reports too many redirects, disable rewrite rules one at a time and record each Location change. Switching between PROXY and DIRECT may affect reachability, but cannot fix two targets that logically redirect back to each other.

When combining these features, first verify normal DNS and routing, then enable Host, and finally test rewriting on its own. If all three layers change at once, it is difficult to tell whether the final address came from resolution, a redirect, or the page itself. Document the purpose of each change and how to undo it. Remove temporary mappings after testing so leftover entries are not mistaken for permanent requirements.

07 Common Rule Combinations and Configuration Maintenance

A maintainable configuration is not one with the most rules; it is one where each request's outcome can be explained with a small set of conditions. Before combining rules, define the default route: should most traffic connect directly with only specified domains using a proxy, or should most traffic use a proxy with clear direct exceptions? Set this in FINAL, then place specific exceptions before broader rules, from narrowest to widest scope.

Combination 1: DIRECT Fallback, PROXY for Selected Domains

This configuration illustrates a setup where only specific hostnames use the proxy route. api.example.com is an exact DIRECT exception, other requests matching the example.com suffix use PROXY, and FINAL,DIRECT handles everything else. The important part is not the example domain, but the order of the exception, domain group, local network rule, and fallback.

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

This example will not automatically match other independent domains used by the service. Base new conditions on request evidence, not a service name turned into a keyword that matches everything similar. If an app relies on multiple requests to complete an action, test the whole flow—including opening, signing in, reading, and submitting—not just whether the entry page loads.

Combination 2: PROXY Fallback with Specific DIRECT Exceptions

Another setup sends requests that do not match an exception through PROXY. It requires a server you already have that can handle the relevant traffic, and a clear understanding of which requests still need a local route. The example keeps one domain exception and one private subnet, then uses GEOIP for address classification. Keep GEOIP only if your actual requirements call for it, not just because it appears in common configurations.

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN,api.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

These are two different approaches to configuration maintenance; do not simply concatenate them. The first FINAL would end rule evaluation before most entries in the second example could take effect. To combine configurations, remove the original fallback lines, organize the specific rules and duplicate conditions, then keep only one FINAL that matches the overall goal. Verify the merged behavior rule by rule.

Update Subscriptions and Configuration Files Separately

Subscribe updates typically apply to your existing server list, while configuration updates may change rules, parameters, or policy references. Updating one does not mean the other is also in sync. If server names in the list change, check whether your custom configuration still refers to names that exist. This guide uses the basic PROXY keyword so rule behavior does not depend on a server name from a tutorial example.

A subscription URL may contain an access token, so treat it as sensitive information. When sharing troubleshooting details, include only the necessary rules and target types; remove full subscription URLs, server authentication fields, and personal identifiers. For the difference between share links and subscription URLs, see Server Link Formats. Their import and update methods differ; the fact that both can be copied as text does not make them the same kind of item.

Save, Switch, and Roll Back

After editing or importing in Config, first check that the file opens correctly and confirm which file is selected. Save, return to Home, and verify that Global Routing is set to Config. Then test with a new request. If you need to reconnect, finish any operation that may be affected first, then switch connections using the controls in the app. Existing long-lived connections may continue using the route they had when they were established.

For rollback, use a verified working copy—not a vague instruction to “delete what you just added.” Record the purpose of each change, the sections involved, the test target, and the observed result. If a remote update overwrites local edits, restore the working copy and verify the basic connection before deciding which entries to merge again. Do not import several configurations from unknown sources while troubleshooting.

A one-time client purchase is not a service plan. Shadowrocket purchases and users' existing connection services are managed separately; this site does not provide, sell, or recommend servers or subscriptions. To check where to get the app and verify the developer, see How to Verify the App on the App Store. Shadowrocket is available only on Apple platforms; check the App Store listing for system requirements.

08 Rule Testing and Troubleshooting

Start by distinguishing among no connection, a connection that is established but requests fail, and successful requests taking the wrong route. Each case requires different evidence. A connection status in Home only indicates the client's current state; it does not guarantee that every destination is reachable. Connectivity Test provides test results, but cannot by itself prove that a particular request matched the expected rule.

Step 1: Set Up a Repeatable Test

Choose one clear action, such as opening a test page you recognize, and record its target hostname, current network, and the failure. Perform only that action to reduce background requests. If the problem occurs only during sign-in or upload, test that step rather than repeatedly refreshing the homepage. Different stages may use different targets; a successful homepage does not verify later requests.

Then record the current file, Global Routing mode, selected server, and most recent change. If the problem started after switching networks, test on both the old and new networks. Do not repeatedly reinstall or reset all settings before recording evidence. Doing so removes the state that could explain the problem and turns a change to one rule into a much broader reconfiguration.

Step 2: Confirm the Configuration Is Being Used

Check which file is selected in Config and confirm that your edits were saved. Then check Global Routing in Home. If it is still set to Proxy or Direct, those results can help compare global routes, but they do not show that a [Rule] condition has failed. Switch back to Config, make a new request, and check whether the target, matching condition, and policy follow the file's rule order.

Global Routing: Config
Config: working copy
Target: api.example.com
Expected Rule: DOMAIN,api.example.com,DIRECT
Expected Policy: DIRECT

This is a record template, not a client runtime log. Record the result you actually observed in this test; do not copy an expected value as though it were an observation. If the target request does not appear in the records, check whether the test reused an existing connection, whether another global condition bypassed the target earlier, and whether the observation time matches your action.

Step 3: Narrow Down the Cause by Symptom

If the wrong rule matches, find the first earlier condition that could match the request. Common causes include an overly broad DOMAIN-KEYWORD, a suffix rule placed before a specific exception, or FINAL in the middle of the file. Fix the order and send a new request. Adding duplicate rules at the end will not help; requests already handled by earlier conditions are not evaluated again.

If the correct policy matches but the connection fails, check what that route requires. For PROXY, verify the address, port, protocol, and authentication details of a server you already have. For DIRECT, check the underlying network and target reachability. For REJECT, first confirm that blocking was intended. Adding a domain rule usually will not fix an authentication failure, and changing DNS will not make a rejected request switch policies automatically.

Step 4: Distinguish Caches, Existing Connections, and Configuration Errors

DNS results and existing connections may temporarily retain an earlier state. After changing a rule, test with a new request you can control; if needed, use the app's controls to reconnect and check again. Do not treat every change in cached results as random configuration behavior. Recording what you observe before the change, after saving, and after a new request helps distinguish an editing issue from a connection lifecycle issue.

If only one app fails, check whether it uses separate domains, a different address family, or a special transport. A successful test page does not prove every protocol path works, and a latency figure does not represent the complete experience. For more on interpreting test results and choosing a server, see How to Interpret Latency Tests and Choose a Server, using only the servers you already have for testing.

Step 5: Document a Verifiable Conclusion

When troubleshooting is complete, keep the smallest effective change and restore any temporary Global Routing mode used for testing. Document which condition caused the problem, which line you changed, how you verified it, and how to roll it back. If the cause remains unclear, save a redacted configuration snippet and notes on what you observed, then consult Frequently Asked Questions. To repeat the initial authorization and import steps, return to the Quick Start Guide.