Shadowrocket Rules and Configuration Reference

01 · Configuration Structure and Editing Safely

Understand the difference between Subscribe and Config

Subscribe is generally used to update a server list, while Config manages connection behavior and request routing. They may come from separate sources you already use. Seeing a server selected in the list confirms that its connection details are in the client; it does not mean a particular ruleset is active. Likewise, importing a complete configuration does not guarantee that its proxy endpoints are available. Before editing, check the selected server on Home, the active file in Config, and the current Global Routing mode. These are separate states, not one switch.

Configuration files use bracketed section names to separate responsibilities. General contains global connection and resolution settings; Rule contains routing rules evaluated in order; Host maps specific hostnames to addresses; and URL Rewrite modifies matching request URLs. Section names are not ordinary labels: do not replace them with translated headings in brackets. Place each setting under its corresponding section. For example, FINAL is a Rule entry, not a General setting. Putting it after General settings without a section marker can produce unexpected parsing or behavior.

# Structure example: section responsibilities only
[General]
dns-server = system

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

[Host]
intranet.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

Edit a copy so you can roll back

The example above is not a complete configuration for every network. In particular, its Host mapping uses a documentation-only address. Remove that example entry before using the file, or replace it with an internal address you actually manage. Before editing an existing file, save a working copy and note its name and mode, then create a separate test file. Change one behavior at a time—for example, add one DOMAIN rule and verify it before changing DNS. If you edit four sections at once, even a successful result will not tell you which change made the difference.

Plain-text configurations use English punctuation. Do not replace equals signs, commas, or square brackets with full-width characters. When copying from formatted documents, check for smart quotes and invisible spaces. Use a hash at the start of a line for a comment; put explanatory text on its own line rather than appending a long note after a rule policy. A file extension does not validate its contents: renaming arbitrary text to .conf does not make its syntax valid. After saving, check that the file loads in Config and that the edited copy is selected.

Local edits and remote updates

A remote configuration may overwrite local changes during a later update. Before keeping custom rules, find out whether the active file is managed remotely, then use a local copy or an editing method supported by the app. Do not assume a change is permanent just because it was saved. Reopen the file, check that the rule remains where expected, and verify it again after an update. Subscription links may contain access credentials; do not include them in public notes or troubleshooting screenshots. When describing an issue, share the rule type and observed behavior instead.

If a file contains sections or fields not covered here, do not delete an entire section just to match an example. Existing settings may handle local networking, name resolution, or specific requests. Understand what a field does before deciding whether to keep it; if in doubt, test against the original copy. Use this reference in order: identify the section’s purpose, review the specific rule, then check the policy and matching order. This separates “the file loads” from “it behaves as intended” and avoids assuming a configuration is usable just because it looks complete.

02 · General, DNS, and Connection Basics

Global settings do not replace routing rules

General settings affect basic connection and name-resolution behavior; Rule determines the policy applied to matching requests. They are related, but neither replaces the other. Changing a DNS server may change the address returned for a domain, but it will not change an explicit DOMAIN rule from PROXY to DIRECT. Editing a Rule also cannot fix a misspelled server address. Troubleshoot domain resolution, request routing, and proxy-server connectivity as separate steps. Do not assume every inaccessible site is caused by a bad rule.

[General]
# Use the DNS provided by the current system
dns-server = system

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

This configuration sends the exact domain example.com to PROXY and sends other unmatched requests to DIRECT. The system value for dns-server uses the DNS settings provided by the operating system; it does not guarantee that every domain will resolve correctly on the current network. If behavior changes after switching networks, check the system network and DNS conditions before changing app settings. Do not copy several DNS addresses from an unfamiliar configuration without checking them. Their reachability, responses, and suitability for the current network all need to be verified; adding more entries does not necessarily improve reliability.

Domain rules and IP rules match different information

DOMAIN and DOMAIN-SUFFIX match hostnames; IP-CIDR and GEOIP match addresses. When a request retains its hostname, a domain rule can determine its route first. An address-based rule may require resolution if only a domain is available. Resolved addresses can vary with the network, cache, and server-side routing, so a domain is not guaranteed to match the same address range every time. When troubleshooting, record both the request hostname and its actual destination address. The browser address bar alone does not show the full connection details.

For IP-CIDR, no-resolve prevents the rule from actively resolving a domain just to evaluate the address condition. It does not mean “the client never uses DNS,” nor does it make the client ignore all domains. If a request already includes an address that can be matched, it may still match the relevant range. If only a hostname is available and no suitable address is present, later rules may be evaluated instead. Add this parameter based on when you want the rule to apply—not as a performance switch that every IP rule needs.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

IPv6, local networks, and cache limitations

An IPv4 range rule does not automatically cover IPv6 addresses. If the network and destination service use IPv6, check whether an IP-CIDR6 rule is needed and how the current connection settings handle address routing. Disabling an address family may temporarily change the symptoms without resolving the underlying issue. Local devices may not all be reachable by hostname: some rely on local discovery, some use fixed addresses, and others listen on different ports. First confirm that the target device is on the same network, then determine whether routing is relevant.

DNS caches and existing connections can delay the effects of a test. After changing DNS or Host, a browser may keep using an existing connection. Send a new request, reconnect if needed, and check the new diagnostic record. Do not keep adding settings just because an old page has not changed. For existing settings such as ipv6 and bypass-system, refer to the app’s own documentation rather than guessing from the field name. System services and local network traffic may also follow paths controlled by the operating system.

If a domain does not open but its address does, do not immediately assume you need a Host mapping. Many services require the correct Host header, TLS certificate name, and server-side routing, so accessing them by address may fail by design. Check resolution, connection establishment, and certificate validation separately before deciding what to change. For more examples, see the FAQ on rules and troubleshooting. Keep the working configuration intact and test resolution changes in a copy to avoid leaving hidden problems behind after connectivity returns.

03 · Rule Types and Parameters

Write the condition first, then the policy

Most common rules follow the order “type, match value, policy,” with fields separated by English commas. The type determines how the next field is interpreted: example.com after DOMAIN means an exact hostname; after DOMAIN-SUFFIX, it means a domain suffix. The policy determines what happens when a rule matches; it is not part of the match condition. FINAL is a special fallback rule and needs no domain or address, so write it as FINAL,PROXY. Adding a third field by habit only makes its meaning less clear.

Choosing between the three domain rule types

DOMAIN,api.example.com,PROXY matches only api.example.com. It does not automatically cover www.example.com or example.com. To apply the same policy to a site’s root domain and subdomains, use DOMAIN-SUFFIX,example.com,PROXY. Suffix matching respects domain boundaries; it is not an arbitrary search for a string at the end. Enter only the hostname as the match value—do not include https://, a port, path, or query parameters. These are not part of the domain and will usually prevent the rule from matching as intended.

DOMAIN-KEYWORD,example,PROXY checks whether example appears anywhere in the domain. It may also match hostnames unrelated to example.com, so it is not a good choice for routing an entire site based only on a brand fragment. Prefer DOMAIN or DOMAIN-SUFFIX when their boundaries fit; use DOMAIN-KEYWORD only when you genuinely need a string match. The keyword ads is not an exact ad list and may match legitimate service domains. If you use it with REJECT, inspect real requests first to avoid blocking normal content.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,tracking,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
USER-AGENT,ExampleClient*,PROXY
FINAL,PROXY

Limitations of address, region, and request-header rules

GEOIP,CN,DIRECT chooses a policy based on the geographic classification of the destination IP—not the page language, the website’s company location, or its domain suffix. Sites using a content delivery network may resolve to addresses in different regions, and address databases have coverage and accuracy limits. For domains that need a predictable route, use an explicit domain rule before GEOIP. The number after the slash in IP-CIDR is the prefix length; larger values usually cover smaller ranges. Use /32 for a single IPv4 address. Do not append a host port to an address as if it were a subnet.

USER-AGENT matches readable request-header content; it is not a general way to “select an app.” Request headers in encrypted traffic are usually not directly visible, so a USER-AGENT rule cannot be expected to cover all HTTPS requests. Do not expand decryption just to make this rule work. The asterisk in the example is part of the match pattern, and ExampleClient is a demonstration label, not a real app. Multiple apps may share a header, and one app may use different values for different requests. Observe the actual destination hostnames instead of relying on this rule as an app identifier.

Keep the rule list focused on real needs. If only one exact hostname needs to use a proxy, there is no need to start with a broad keyword, an entire region, and a large address range. Conversely, to control all subdomains of a site, you do not need to list every hostname you have seen. Reproduce the expected behavior with the narrowest conditions first, then widen the scope only if necessary. Look up unfamiliar keywords in the terminology reference, but verify them against actual requests rather than assuming a rule works based on its name.

04 · PROXY, DIRECT, REJECT, and Modes

Rule policies and Global Routing are separate choices

PROXY sends a matched request through the currently selected proxy; DIRECT connects to the destination directly; REJECT denies the request. These policies are not separate sets of server details, and the configuration does not create a server named PROXY. Before using PROXY, make sure the server details you already have are imported correctly and select an appropriate endpoint on Home. If the file uses a custom policy group, confirm that it is defined in the configuration, spelled consistently, and contains a usable endpoint.

Config mode is the primary environment for verifying Rule-based routing. Proxy and Direct modes can help compare connection paths, but they do not prove that a Rule is in the correct order. Operating-system services, local networks, and app-specific settings may have their own limits; do not interpret a mode name as unlimited control over every device connection. Before switching modes for a test, note the original setting. Restore Config afterward and use a new request to confirm rule behavior, so later results are not skewed by a forgotten mode change.

DIRECT does not mean “disable the client”

A DIRECT rule tells a matching request to connect directly. It does not turn off Shadowrocket or invalidate the rest of the configuration. The client may still handle other requests, resolve names, or record diagnostic information. You can use a more specific DIRECT condition for local addresses, internal services, or domains that already work over a direct connection. Whether the connection succeeds still depends on the network route, firewall, and destination service. DIRECT is not a fix for every connection restriction.

[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,DIRECT

This snippet puts intranet.example.com before the suffix rule as an exception, so it connects directly while other example.com hostnames may use PROXY. blocked.example.org is explicitly rejected. The final line, FINAL,DIRECT, sends unmatched requests directly; requests already matched by earlier rules do not fall through to it. Read each line as an independent test: check the condition, then the policy, and finally its position in the file to understand what it covers.

The effect of REJECT versus a failed connection

REJECT actively denies a request; it does not mean “fall back to a direct connection if the proxy fails.” If a rule intentionally rejects a target, a blank page, missing resources, or an app network error may be expected. Before using REJECT, confirm the target can be blocked without affecting other functions such as sign-in, images, or API calls. If removing a REJECT rule restores the page, narrow the match instead of assuming every request to the site must use a proxy. Broad keyword matches are especially likely to cause collateral effects.

If a PROXY route fails, do not immediately change FINAL to DIRECT. The failure may be in server name resolution, port connectivity, protocol authentication, or access to the destination. Changing the fallback affects all unmatched requests and may hide the original issue. First use Connectivity Test or a request to a specific destination to check whether the selected endpoint works, then verify the server details you already have. A successful connection test does not guarantee that every website will be reachable.

On Demand controls when a connection is established or restored, not which domains match. Its role differs from Global Routing and Rule. If no connection is established, check the connection status and On Demand conditions first; if the connection is up but traffic takes the wrong route, inspect routing rules. Custom policy groups may add another choice to the chain, so check in this order: current mode, matched rule, selected policy, actual endpoint. For more on modes, see Proxy modes. Repeatedly toggling the connection is no substitute for checking the policy chain.

05 · Matching Order, Priority, and Fallbacks

The first match wins; rules are not sorted by name

Common rules in Rule are evaluated from top to bottom in file order. A request that matches an earlier rule usually does not continue to later, more specific rules. DOMAIN does not automatically outrank DOMAIN-SUFFIX because it “looks more precise,” and IP-CIDR does not inherently take precedence over GEOIP. Priority comes first from position. Put explicit exceptions first, broader rules after them, and the fallback last. This order is easier to read and reduces conflicts when adding rules later.

[Rule]
# Put the specific hostname first as an exception
DOMAIN,api.example.com,DIRECT
# Route other requests for the same site through the proxy
DOMAIN-SUFFIX,example.com,PROXY
# Send unmatched requests directly
FINAL,DIRECT

In this order, api.example.com gets DIRECT from the first line. www.example.com does not match that line, but matches the second and gets PROXY. If you swap the first two lines, api.example.com matches the suffix rule first, making the direct exception ineffective. To test priority, choose a target that matches both conditions; that is the only way to demonstrate the effect of order. Testing two unrelated domains does not verify which rule takes precedence.

FINAL does not let unmatched requests continue to later rules

FINAL handles requests not matched by any earlier rule and should usually be the last entry in Rule. If placed in the middle, it prevents later regular rules from handling the remaining requests. When appending a rule to the end of a file, check that it has not been placed after FINAL. Multiple FINAL entries do not create fallbacks that switch automatically by scenario. If different scopes need different policies, define their conditions explicitly instead of using repeated fallbacks to express an unclear requirement.

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

In this snippet, the domain exception comes before address classification. Even if example.com resolves to an address that could match GEOIP, a request already matched by the domain rule follows that policy. If a request does not include information usable for a domain match, continue to check the address conditions. This is not random rule behavior: what a rule can match depends on the information available when the request enters the processing flow. Record the hostname, destination address, matching line, and final policy to distinguish order issues from match-condition issues.

Duplicate rules, overlapping matches, and remote content

Duplicate rules do not necessarily cause a syntax error, but they make maintenance harder. If the same DOMAIN-SUFFIX appears first with PROXY and later with DIRECT, the later rule usually cannot override the first as intended. Before editing, search for the same domain and check for broader suffix or keyword rules, then look for earlier address-based matches. Keep an original copy before removing duplicates, and confirm that it contains no necessary exceptions. The goal is to make every rule’s effect understandable, not simply to reduce the line count.

If the current configuration also references external rule content, check where those references appear in the main file. It is not enough to inspect the external list: also check when it participates in matching, which policy handles it, and whether an update changes its scope. Do not assume an unfamiliar reference has priority based on its name. Test the standalone examples in a local copy first, then compare them with the existing configuration one item at a time. Avoid inserting snippets into an unknown section without checking their effect.

A useful order test needs only a few rules: one exception, one range rule, and one FINAL. Once all three behave as expected, restore other entries in small batches. After each batch, test the same destinations and check records from new connections to identify which batch introduced an overlap. If a site works in Proxy mode but not Config mode, check the matched policy before reinstalling the app. For a complete example of routing only selected sites through a proxy, see how to write DOMAIN-SUFFIX rules.

06 · Host and URL Rewrite: What They Do

Host changes name resolution, not the route policy

The Host section maps hostnames to addresses. It answers “which address does this name resolve to?” rather than “which policy should the connection use?” For example, if an internal service needs a fixed address you manage, add an explicit Host mapping and select DIRECT in Rule if that suits your needs. Treat the sections separately: a Host mapping alone does not guarantee a direct connection, and DIRECT does not supply the correct internal address. The mapped address must belong to the intended service, or even a precise rule will connect to the wrong destination.

[Host]
intranet.example.com = 192.0.2.10

[Rule]
DOMAIN,intranet.example.com,DIRECT
FINAL,PROXY

192.0.2.10 is a documentation-only address. This example illustrates syntax and must not be used as an internal service address. Before entering a real value, check it against information from your network administrator or service configuration. If the service address changes between networks, a fixed Host entry may work on one network and fail on another. If the service uses multiple addresses for traffic distribution, pinning it to one address may also break failover. Do not use a permanent static mapping instead of investigating a resolution problem, and do not copy an old address from an unfamiliar note.

A mapping does not change the TLS name or server configuration

For an HTTPS request made using a domain, the connection address and the name used for certificate validation are different concepts. Host can change the destination address, but the server must still present a suitable certificate and response for that domain. If a mapping causes a certificate error, do not treat bypassing validation as proof that the configuration is correct. First confirm that the destination service supports the domain and that its server-side site binding is configured correctly. Multiple sites can share an address; being able to connect to that address does not prove it will return the content you need.

Cache and connection reuse can affect tests after a Host change. Save the file, confirm it is selected, and then create a new request. If necessary, close and reopen the old page and check the actual destination address. If only one app is unaffected, it may use its own name resolution or connect directly to an address. Do not assume every request on the device follows the same path just because another app uses the mapping. Keep a note of each static mapping’s purpose and source, and review it after service changes to avoid unexpected failures.

URL Rewrite matches and modifies request URLs

URL Rewrite modifies matching request URLs. It is not a server-list update or another name for domain routing. A common form consists of a match expression, replacement URL, and action. The example below uses a redirect to send HTTP requests for a sample site to HTTPS while preserving the original path with a capture group. Escape the period in the regular expression and use a start anchor to constrain the match. Otherwise, a seemingly simple expression may also match unrelated URLs. Before using a rule, list examples that should and should not match; do not validate it with only one successful case.

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

Here, $1 refers to the content captured by the preceding parentheses, and 302 tells the client to continue at the replacement URL. The destination site must actually support HTTPS; the rule cannot add a certificate or create a page on the server. A redirect may also change the request hostname and trigger a different Rule. If the final route changes, check whether the destination changed. If the replacement URL matches the original expression, or the server redirects back to the old URL, a loop may result. Disable the rule and inspect the full redirect chain.

Paths and request headers in HTTPS traffic are usually encrypted, so not every URL Rewrite rule can act on them directly. Decryption also has certificate trust, hostname-scope, and app-compatibility limits. You do not need to enable decryption to set up routing rules, and expanding its scope just to test a simple condition is not recommended. For routing by domain, use Rule first. Host, Rule, and URL Rewrite address different problems. When combining them, verify name resolution, the policy, and the rewritten request separately; a successful redirect does not prove the entire configuration is correct.

07 · Common Rule Patterns and Adjustments

Route only selected sites through PROXY

To route a few selected sites through a proxy and connect to other destinations directly, use explicit domain conditions followed by FINAL,DIRECT. Start with one destination you can verify rather than importing a large set of unchecked keywords. The example routes example.com and its subdomains through the proxy while keeping an internal hostname direct. Before using it, replace the example with a domain you actually need to manage and confirm that your proxy endpoint works. The example domain illustrates matching behavior; it is not a real service for connection testing.

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

A real website may use more than the domain in the address bar. It may also request a separate login API, static assets, or file services. If text appears but images do not load, inspect the missing resources’ actual requests instead of routing all traffic through PROXY. Add a DOMAIN or DOMAIN-SUFFIX rule only after confirming that a resource belongs in the scope you need to change. A broad suffix may affect other sites if they share the same service domain; an exact hostname is usually easier to keep narrowly scoped.

Add explicit exceptions, then route other requests through PROXY

Another common need is to use DIRECT for internal services, local network addresses, or addresses in a particular region, and PROXY for other requests. In this case, FINAL,PROXY is only the fallback; it does not make every request use the proxy from the first line. Put known exceptions before it, and order hostname and address conditions according to how specifically they apply. Put a domain that must use the proxy before a regional rule if it should not be routed DIRECT based on its address classification. Regional classification cannot replace explicit rules for critical services.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,intranet.example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

This example lists only some internal address ranges and is not a complete inventory of every local network. Home, office, and virtual networks may use different addresses and discovery methods. Add conditions based on the actual network topology instead of copying the example and assuming all local services are covered. Keep the limits of no-resolve in mind: it prevents an address condition from actively resolving a name; it does not resolve internal hostnames to addresses. If an internal name does not resolve, check system DNS, Host, or your own internal DNS settings.

Reject a specific target without blocking too broadly

When you need to reject a confirmed request target, start with DOMAIN rather than using a common word in the name to create a broad REJECT. An exact hostname is easy to verify and remove. This example rejects only telemetry.example.com while leaving proxy behavior for other example.com hostnames unchanged. Switching to DOMAIN-KEYWORD,telemetry,REJECT could affect unrelated domains containing the same string. Decide whether to broaden the scope based on real request records and a clearly defined need—not on whether a rule looks more comprehensive.

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

When testing REJECT, check that the intended request is blocked, the page’s core features still work, and sign-in or submission flows are unaffected. An endpoint may handle both analytics and essential responses; its name alone does not reveal the impact of blocking it. If something breaks, disable the newly added exact rule and repeat the same action. Once you confirm the cause, decide whether to keep or remove the rule. Do not add a growing set of exceptions just to preserve a block until the configuration becomes an unmaintainable patchwork.

Turn patterns into maintainable notes

These three snippets are starting points for different needs, not blocks to concatenate: each has its own FINAL. When combining them, choose one overall fallback, keep only the necessary domain exceptions, internal addresses, and rejected targets, then review their order. For each new condition, record its purpose in one line—for example, “internal API must connect directly” or “route selected site through proxy.” Do not record subscription credentials. When a need goes away, remove its rule by purpose rather than guessing which entry it was among hundreds or thousands of lines.

If only the PROXY route stops working after you replace an existing subscription, check the selected server and connection details before rewriting domain conditions. The rules may still point to the same policy; the endpoint behind that policy may have changed. For groups and duplicate servers across multiple subscriptions, see managing multiple subscriptions. Keep the responsibilities distinct: server details belong with server management, target matching belongs in Rule, and name resolution belongs in General or Host. This separation makes it easier to locate what needs adjustment when the network changes.

08 · Testing, Troubleshooting, and Maintenance

Choose consistent test targets and keep a record

Do not test a configuration only by asking whether a page opens. Confirm that it uses the intended route. Choose one domain that should use PROXY, one that should use DIRECT, and one unlisted domain for testing FINAL. If you use REJECT, add a clearly identified target for that too. Write down the expected policy for each test, then record the actual destination, matched rule, and final endpoint. Fixed targets make before-and-after comparisons useful; changing sites each time can make server-side changes look like configuration changes.

1. Confirm that your existing server details are imported and select a working endpoint on Home.
2. Select the test copy in Config and set Global Routing to Config.
3. Connect, then visit the fixed test target with a new request.
4. Check the matched condition and policy in the request log or diagnostic view provided by the app.
5. Change one thing at a time and repeat the same tests. Save a rollback copy once everything works.

Connectivity Test can help assess certain connection conditions, but it cannot replace testing the actual service. A successful connection to a server does not guarantee that a website’s authentication, resources, or request methods will work. Likewise, one failed page does not prove the server is unavailable. First identify whether the failure occurs during resolution, connection, rule matching, or the app-level response, then choose the right diagnostic tool. If you do not have enough information, a minimal reproduction is more useful than repeatedly changing many settings.

Choose a troubleshooting path based on the symptoms

For a rule that does not match, first check the actual hostname instead of immediately broadening the suffix. A page may redirect to another domain, an app may call an API host, or a request may use an address directly. If the condition is correct, check that the file is selected and saved, and that Global Routing is not still set to Proxy or Direct. Then look for an earlier matching rule, especially a broad keyword, an address rule, or a FINAL placed too early. This order of checks prevents a state issue from being “fixed” by adding more rules.

If a rule matches correctly but the request fails, investigate the connection path. Check the server address, port, authentication details, and protocol-specific settings you already have; do not use a broader Rule to hide an authentication problem. For Trojan and other TLS-based connections, verify the name and settings provided by the service. Use the details from your own service, not values inferred from a rule example. See Trojan password, SNI, and TLS settings for related fields. If the server list is empty, resolve the subscription update issue first; rules cannot replace missing server details.

Rollbacks, updates, and troubleshooting notes

After each successful change, save a stable copy with a clear purpose and note the condition you changed and why. After updating a remote configuration or subscription, retest your existing targets before waiting for every app to show a problem. If new content causes an issue, restore the verified copy to re-establish a baseline. Then compare sections one by one instead of mixing old and new files and continuing to patch them. Remove obsolete Host mappings, outdated exceptions, and duplicate rules only after confirming nothing depends on them.

When collecting troubleshooting details, keep only what is needed: the current mode, a few surrounding lines of the relevant Rule, the test domain, expected policy, and actual result. Do not share full subscription links, server passwords, access tokens, or request URLs containing personal information. Check screenshots for exposed details before sharing them. If the cause is unclear, reproduce the issue with a minimal ruleset first, then consult the FAQ and subscription update troubleshooting guide. This helps distinguish subscription parsing problems from rule-routing problems.