Shadowrocket Settings Guide

Chapter 01

A reliable reading order and recoverable baseline for Settings

Separate connection state, routing mode and setting values first

Common Shadowrocket issues are rarely caused by one switch alone. They usually result from the combined effect of the Home connection state, the current Global Routing mode, the selected Config, server details and Settings values. Before changing anything, open Home and confirm that the selected server or Config is the one you expect. Then record whether Global Routing is set to Config, Proxy or Direct. Config matches traffic against the Rule entries in the configuration; Proxy sends applicable traffic through the current Proxy; Direct connects without it. These modes serve different purposes. Do not treat a result observed in Direct as evidence that Config rules are failing, and do not use Proxy mode to determine whether a specific DIRECT rule matched.

Settings is best suited to controlling DNS resolution, connection triggers, testing methods, logging, synchronization and local ports. It does not replace server details or automatically supply services that have not been configured. This guide assumes that you already have your own Subscribe URL or server parameters and understand that they must be maintained by their original provider. Shadowrocket is a one-time purchase from the App Store; a one-time app purchase is not a line subscription, and buying the app does not include server details. For a way to verify the developer name Shadow Launch Technology Limited, app ID 932747118 and the store listing, see the genuine-app verification section of the download guide.

Record four items before making changes

Before changing any setting, write down four baseline items. First, note the network environment, such as home Wi‑Fi, office Wi‑Fi or cellular data. Second, record the server entry actually selected in Home. Third, note the current Config name and Global Routing mode. Fourth, describe the reproducible symptom, such as “only one domain fails to resolve,” “the connection does not start automatically after switching to cellular,” or “Connectivity Test stops at a particular stage.” These details turn a vague “it does not work” into verifiable conditions and make it easier to tell whether the original state has been restored.

Use a single-variable method: adjust one item, save it, disconnect and reconnect, then repeat the same verification step. If you change DNS, Config, server and On Demand conditions together, you cannot tell which change helped even if the issue temporarily disappears. If a new issue appears, reversing it is equally difficult. Single-variable notes are especially important for DNS, IPv6, Proxy ports and iCloud sync because these settings can affect multiple scenarios.

How to interpret default and recommended values

Default states in Settings may vary with the store version, device system and migrated configuration. This guide therefore does not present one fixed number as the default for every device. When reviewing an item, distinguish between the value currently shown by the client, the state provided by the system after a fresh installation and parameters explicitly declared in Config. Explicit Config entries are usually easier to reproduce than relying on interface defaults, provided the syntax is correct and you understand the scope of each parameter.

A recommended value is not necessarily the most complicated one. For stable everyday use, keep the value that already works in the system or Config. Add an override only when you can describe the specific problem it addresses. Adjust DNS when resolution fails, inspect On Demand when network-switch behavior is unexpected, and revisit Ping or Connectivity Test methods only when test results do not match actual access. This order prevents diagnostic tools from being mistaken for speed features and reduces leftover settings whose purpose is forgotten.

Chapter 02

DNS: resolution paths, value selection and failure isolation

Where DNS fits in the connection process

When accessing a domain, the device must resolve it to an address before establishing the subsequent connection. A node returning a latency result only shows that the test target and path were reachable at one stage; it does not prove that every domain resolves correctly. Therefore, “Ping looks normal but the page will not open” should put DNS on the checklist. Shadowrocket DNS behavior may be affected by the system network, Settings, the current Config and individual Rule entries. First determine whether every domain fails, only a particular suffix fails, or the issue appears only after switching networks.

System DNS is a useful baseline. If common sites also fail in Direct mode, check the current Wi‑Fi or cellular network before changing complex parameters. If Direct and Proxy work but some domains fail in Config, inspect rule matches and the Config DNS declarations. If only one domain is affected, compare its main domain, subdomains and behavior when its address is entered directly, so an outage at the target service is not mistaken for a global DNS failure.

Three boundaries to consider when choosing a resolution method

First, determine where the DNS request originates. When using the system resolution path, results generally follow the current network. If DNS is specified in Config, confirm that the address is reachable from the current network. Second, determine how the result is passed to rule matching. DOMAIN, DOMAIN-SUFFIX and DOMAIN-KEYWORD match domain names directly, while GEOIP, IP-CIDR and IP-CIDR6 require address information. Third, consider when the cache is refreshed. After changing DNS, disconnect, wait for the system network state to refresh, reconnect and test the same domain again if an old result still appears.

For everyday use, start with a system resolution path that is known to work reliably instead of adding several DNS addresses for an isolated symptom. If Config must specify DNS, keep the list short and record its order; an unreachable preferred address can make every query wait for a timeout. With encrypted resolution, also consider how the service domain itself is resolved initially. If that initial path is blocked, the result may be “a more advanced setting that cannot resolve anything.” During troubleshooting, return to the simplest path and add conditions one layer at a time.

How Config DNS works with rules

A configuration can explicitly record DNS and Rule entries, but do not paste an unfamiliar example wholesale into a working Config. First duplicate the configuration as a test copy, then add only what is necessary. Rules match from top to bottom, so more specific domain rules generally belong earlier; FINAL handles connections not matched above. If DOMAIN-SUFFIX has already sent a domain to PROXY, a later GEOIP rule will not rewrite the policy for that same request. When diagnosing DNS, check both whether resolution succeeded and which rule ultimately matched.

[General]
dns-server = system

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

The snippets above illustrate structure and match order. example.com is a documentation example domain and does not represent a real service; dns-server = system means that the system resolution path is used as the baseline. An actual Config may also contain proxy groups, remote rules and other General items. Preserve the existing section structure when merging, and avoid duplicate section headers or spelling errors. After saving, first confirm that the Config can be read normally, then test the rules instead of adding more DNS addresses while resolution is failing.

Step-by-step troubleshooting for resolution failures

First switch to Direct and test two unrelated domains. If both fail, address the local network; if both succeed, continue. Second switch to Proxy while keeping the same server. If it fails, check the server connection and protocol parameters before changing Rule entries. Third switch to Config and see whether the issue appears only in rule mode. Fourth open Log and find the result matching the target domain, confirming whether DOMAIN-SUFFIX, GEOIP or FINAL took control. Only then change DNS, reconnecting after each change.

If the issue is “sometimes works, sometimes fails,” record the time, network type and whether Wi‑Fi was just switched. Intermittent failures often involve a preferred DNS address timing out, a connection not being rebuilt after a network change or a different order of returned addresses. Do not draw conclusions by repeatedly clicking Ping; use actual domain requests together with Log and Connectivity Test. For a fuller layered example, read DNS settings and resolution-failure troubleshooting.

Chapter 03

On Demand: automatic connection conditions and network changes

What On Demand is for

On Demand triggers a connection based on network state. It does not replace the manual switch in Home and does not determine automatically whether a particular server is suitable. Before enabling it, confirm that manual connection is stable: on a fixed network, select a specific server and Config, connect manually and verify access. If manual connection already fails, On Demand will only trigger the failure more often and may make it difficult to tell when the client reconnects.

The most common use of automatic connection is maintaining the intended state when switching between Wi‑Fi and cellular networks, or applying different actions to known networks. Start with a small set of clear, non-overlapping rules. Every condition should answer three questions: what type of network does it match, what action follows, and what happens when nothing matches? Do not describe the same network with overlapping ranges, because the result then depends on match order and becomes harder to troubleshoot.

Classify networks first, then choose actions

Daily environments can be grouped into trusted fixed Wi‑Fi, other Wi‑Fi and cellular networks. “Trusted” here only means that you know the network and want to assign it a separate action; it is not an absolute security judgment. Fixed Wi‑Fi is usually identified by its network name, other Wi‑Fi acts as a fallback, and cellular is handled separately. If the device often connects to different networks with the same name, do not rely on the name alone for complex decisions; keep a manual confirmation step.

Choose actions around real needs. If you want Shadowrocket to connect automatically on a particular network, assign connection behavior to that condition. If you want manual control, do not force a trigger for that network. Test every environment after configuration rather than merely checking that the switch is on. Stay on one network and record the Home state, switch to a second network and wait for the system to finish changing networks, then check whether the connection is rebuilt. Finally return to the first network and confirm that the behavior is repeatable.

Condition order and conflict checks

Specific conditions should come before broad ones. For example, a rule for one fixed Wi‑Fi should precede a fallback such as “any Wi‑Fi.” If the broad condition matches first, the specific condition later may never take effect. After changing the order, repeat the network-switch test and check that Home shows the expected state. If the connection repeatedly changes or the switch toggles several times in a short period, first suspect overlapping conditions, the system moving between access points, or a Config that cannot connect on the new network.

On Demand is closely tied to system network state. Just after unlocking, when signal strength is weak or while Wi‑Fi is obtaining an address, connection setup may lag behind an interface change. Do not repeatedly toggle the switch; manual actions may overlap with automatic triggers. Wait for the network state to stabilize, then check Log for a new connection process. If automatic triggering selected the wrong server or Config, inspect what Home actually selected before the switch rather than blaming the On Demand condition itself.

Recommended enablement sequence

First turn off On Demand. On your usual Wi‑Fi, connect manually and verify DNS, rules and access. Second, keep the server and Config unchanged and repeat the manual verification on cellular. Third, create only the most-used condition, enable On Demand and complete one round-trip network switch. Fourth, check Log to confirm that each network change triggers one clear reconnection. Fifth, add a second network condition. If any step fails, remove the condition just added instead of expanding the setup.

When temporarily troubleshooting network issues, turn off On Demand so automatic reconnection does not interfere with comparison tests. After disabling it, still check the current connection state in Home; stopping automatic triggers does not immediately change an existing connection. Once troubleshooting is complete, restore a working manual state before enabling On Demand again. This separates “is the connection usable?” from “are the automatic conditions correct?”

Chapter 04

Ping and Connectivity Test: interpreting test results

A latency number is not complete connection quality

Ping provides a quick view of whether a target responds under the selected test method and of its approximate round-trip time. It can reveal an unreachable entry, an obvious timeout or a large difference within the same network, but it cannot by itself prove that web, video or other application traffic works. Actual connections also involve DNS, the target port, protocol handshake, transport parameters, rule matching and the target service response. Choosing a server solely by one latency result can mistake temporary jitter for a stable difference.

Fix the test conditions before running Ping: use the same network, Global Routing mode and test method, and do not switch Wi‑Fi during the scan. Observe at least two or three rounds, focusing on persistent timeouts and excessive variation rather than the smallest single number. If every entry worsens at once, check the local network first. If one entry remains abnormal, inspect its server details or network path. Test data is for diagnosis, not for making long-term performance claims.

The layered value of Connectivity Test

Connectivity Test is better for answering “where does the connection process stop?” The available checks may vary with the current interface and network, but the reading order should remain the same: confirm basic local connectivity, confirm that the server address is reachable, then observe whether the protocol handshake and actual request complete. Passing one stage only proves that stage; later stages may still fail. For example, a reachable server address does not prove that authentication parameters are correct, and a successful protocol handshake does not mean DNS and Rule will send the target request to the expected policy.

When a test fails, record the earliest failed stage rather than only the final red result. The first failure is closest to the cause: if it stops during resolution, go to the DNS section; if the server connection times out, check network reachability and server details; if the actual request fails after earlier stages pass, inspect Rule, FINAL, the target service and transport parameters. Repeat the same test after each change to see whether the failure moves later or disappears.

How to reduce test error

Close foreground tasks that continuously generate network requests so Log is easier to read, but do not change every system setting. Keep the device location and access point unchanged. Test a known-working entry as a control before testing the target entry. On cellular, signal changes directly affect latency; on Wi‑Fi, access-point changes and local congestion can also cause variation. After a single timeout, repeat the verification before changing protocol parameters.

When comparing servers, make sure the test method is identical. Some tests verify only TCP establishment, while others may include an actual request; numbers from different methods are not directly comparable. Use the Ping methods actually shown in Settings. If you do not understand an option, keep the default or current working method instead of switching repeatedly for a smaller number. Troubleshooting slow access also requires separate checks of the local network, server, network conditions, protocol and target service; see layered troubleshooting for slow speeds.

From test results back to Settings

If every Ping times out but Direct access works, check whether the test uses the current Proxy, whether the server address is reachable and whether protocol parameters are complete. If Ping works but Connectivity Test fails during resolution, follow the DNS path. If both are normal but access is unexpected in Config, inspect Log for DOMAIN, GEOIP, IP-CIDR or FINAL matches. If Proxy works but Config fails, the issue is more likely in the rules or configuration than in the server itself.

After diagnosis, restore temporary test settings to the state needed for long-term use. If you switched to Direct for comparison, explicitly restore Config afterward. If you increased Log detail, adjust it back to your actual needs. If you changed the selected server to test it, confirm that Home ends on the expected entry. A diagnosis is not complete merely because the issue temporarily disappears; the configuration must also return to a clear and repeatable state.

Chapter 05

Log and Data: reviewing rule matches and traffic records

Questions Log should answer

Log is primarily for reconstructing the decisions made for a request, not just for finding conspicuous error text. For each record, review the time, target domain or address, matched Rule, final policy and failure stage in that order. For rule issues, the key question is whether the request matched the expected DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, IP-CIDR6 or FINAL. If it matched an earlier rule, return to Config and adjust the order instead of repeatedly switching servers.

Before recording, remove unrelated activity from the test: keep one target, perform one open or refresh, then return to Log and inspect that time window. Background apps generate many system requests, so an unfamiliar domain is not automatically a problem. Use time, target and repeated actions to establish the relationship. For example, visiting the same example domain twice and seeing two similar records close together makes it easier to identify which records belong to the test.

How to read errors by layer

Resolution errors usually point to an unreachable DNS address, no result for the domain or a resolution path that has not recovered after a network change. A connection timeout is more likely related to the server address, target port or network path. Handshake or authentication failures require checking whether the protocol, password, UUID, transport parameters or certificate-related settings in the existing server details match. An unexpected rule match calls for checking Config order and keywords. Different layers require different responses.

If an error occurs once and later requests succeed, first observe whether it coincided with a network switch or brief timeout. If every attempt fails at the same stage, use a single-variable check for that stage. Do not export a large log and search only for “error”; the preceding connection action and following fallback policy are equally important. A timeline is more valuable than an isolated error word.

What Data is useful for

Data shows an overview of traffic and connection usage recorded by the client. It can help reveal whether an app or domain keeps generating requests and provide a comparison before and after rule changes, but it cannot independently determine billing, network quality or server status. System accounting, connection reuse and caching can make Data differ from the page size visible to the user, so treat it as trend information rather than an exact bill.

When reviewing Data, limit the time range and test action. Before changing a DOMAIN-SUFFIX rule, record how the target behaves under the current policy. After the change, reconnect, perform only the same request and compare whether the expected policy handled it. If background apps keep generating traffic, do not use the total to judge one target. Investigate unusual growth in Log by checking the specific domain and policy rather than deleting a Config or server entry based only on Data.

Preparing diagnostic information for sharing

When reporting an issue to the provider of your server details, include the time, network type, protocol name, earliest failed Connectivity Test stage and a redacted Log excerpt. Server addresses, passwords, UUIDs, access credentials in Subscribe URLs and other sensitive parameters should not appear in public screenshots or text. You can retain domain suffixes, the failure stage and rule keywords to show which layer is involved.

Do not rewrite the meaning of an error when preparing logs. If content must be hidden, replace sensitive parts consistently while preserving field structure and nearby context. For example, retaining the sequence “a target matched DOMAIN-SUFFIX, used PROXY and then timed out” is more useful than sharing only the final failure page. After the issue is resolved, delete temporary diagnostic exports and restore the Log scope needed for everyday use.

Chapter 06

Widget and iCloud sync: quick actions and configuration migration

Widget is a shortcut, not an independent connection

Widget provides a shortcut for viewing or triggering common states from the system interface, but it still depends on the servers, Config and connection permissions already present in Shadowrocket. If Widget looks wrong, first open Shadowrocket and confirm that Home loads normally and can connect manually, then check whether the system allows Widget refreshes. If the client has not completed its initial connection authorization, using Widget alone cannot bypass that step.

Use Widget for high-frequency actions with clear meanings. If several servers or Config entries have similar names, a shortcut can select the wrong one. Names should indicate purpose but must not contain passwords, address credentials or other sensitive data. After changing an entry in Shadowrocket, if Widget still shows the old state, confirm inside the client that the change was saved, then let the system refresh Widget instead of repeatedly deleting a working configuration.

Widget state does not match the actual state

The system may delay Widget refreshes for battery and resource management, so its display can briefly differ from the live Home state. Judge whether a connection exists by opening Shadowrocket, checking Home and verifying an actual request. If tapping Widget produces no expected action, check whether the device has just restarted, whether the client is waiting for permission confirmation, whether the current network works and whether On Demand triggered another connection action at the same time.

Use this order: complete one manual connection from Home; return to Widget and perform the same action; if Home succeeds but Widget fails, remove and re-add the system Widget; if both fail, the issue is not Widget and you should investigate server details, DNS or network tests. Do not change Proxy ports or Rule entries during a Widget issue; these settings are usually unrelated to system shortcut refresh.

What iCloud sync can and cannot do

iCloud sync saves or synchronizes app data between eligible Apple devices. The exact data covered and how it appears follow the current Shadowrocket interface. It is not the same as real-time, conflict-free, two-way replication of every item and should not replace a manual backup. Before enabling it, check the iCloud state on each device and decide which device provides the current baseline. Editing a same-named Config on multiple devices can cause old content to overwrite new content or create confusing copies.

Use a “modify on the primary device, verify on the others” workflow. Finish and verify the Config change on the primary device, recording the configuration name and key Rule entries. After sync, open Shadowrocket on another device and check the server entries, Config content and Global Routing against expectations. If nothing has updated, do not immediately edit the same-named item on the second device, as this may create a new conflict. First check iCloud status, network access and whether the client has finished loading.

Import, sync and Subscribe updates compared

Import from Cloud JSON is a one-time import action, iCloud sync is a data-synchronization mechanism between devices, and Subscribe updates refresh the relevant entries from the user's existing Subscribe URL. Do not treat them as the same thing. Imported JSON is a copy of the data at import time; future changes depend on how it is maintained. A Subscribe update may regenerate related entries from the source, so whether manual edits remain should be checked in the actual result. iCloud may carry local changes to other devices.

Before any bulk change, preserve a working Config and record the currently selected server. After updating, do not immediately delete old entries. First check that the new entry has the correct protocol, address, port and name, then run Ping or Connectivity Test and verify the Rule through Config. When duplicates appear, identify their source before deciding which to keep; deleting by matching name alone may remove an item still referenced by Config.

Cross-device verification checklist

After migrating between iPhone and iPad, check at least five items: the current server in Home, the Global Routing mode, whether Config exists and opens, whether On Demand suits that device's network environment, and whether Widget points to a valid entry. Device use cases differ, so On Demand conditions should not necessarily be identical. For example, an iPhone that moves between networks and an iPad that stays on fixed Wi‑Fi can share a base Config while maintaining separate automatic connection conditions.

Compatibility information for Mac, Apple TV and Apple Vision is available on the same App Store product page; system requirements are as listed there. Even when data syncs successfully, verify network permissions, available interface items and the actual connection result separately on each device. Completed sync only means the data may have arrived, not that the connection environments are identical.

Chapter 07

Proxy ports: local listening, LAN access and conflict checks

What a Proxy port means

The Proxy port in Settings lets local apps hand connections to Shadowrocket through a specified HTTP or SOCKS5 entry. It is a local listening number on the device, not a remote server port and not the service port in a protocol configuration. Even if the numbers happen to match, their meanings remain different. Changing a Proxy port will not fix an incorrect server password, UUID or transport parameter, and it does not change Config rule order.

If you only use the system connection switch, you usually do not need to change local Proxy ports often. Pay attention to them when an app explicitly supports manually entered HTTP or SOCKS5 Proxy settings or when performing local debugging. Use the address and port currently shown in Shadowrocket Settings rather than numbers from another device. The port must be within the valid range and should not conflict with another service listening on the device.

Local and LAN addresses are different

A local app connecting to a local Proxy usually uses a loopback address or the local entry shown in Settings. A loopback address points only to the current device; another device cannot use its own loopback address to reach this iPhone or iPad. For another controlled device on the LAN to connect, confirm that Shadowrocket has the relevant LAN listening capability enabled, that the system has granted local-network access and that you are using the actual address of the device providing the service on the current LAN.

LAN access expands the listening scope. Enable it only when necessary, when the network is controlled and when you understand who can connect. Restore the original state after debugging. Public Wi‑Fi or a network with unknown peers is not suitable as a long-term shared entry point. Even with listening enabled, the other device must be reachable on the same network; client isolation, guest networks and router policies can all block the connection.

Port-conflict symptoms and handling

A port conflict may appear as listening failing to start, an app connection being immediately refused or access failing despite a correct address. Restore Shadowrocket's original port and reconnect first. If the original works but the new one does not, the new port may be occupied or entered inconsistently. After changing it, update every app that uses the local Proxy; old configurations do not follow automatically. Do not change both HTTP and SOCKS5 ports at once, or you will not know which one conflicted.

The protocol type matters too. When an app requires HTTP Proxy, enter the HTTP endpoint; when it requires SOCKS5, enter the SOCKS5 endpoint. Crossing the type and port can cause connection failure or abnormal requests. If the app supports authentication fields but Shadowrocket's local entry does not require the same method, follow the client's actual settings instead of adding remote server credentials yourself.

Minimal steps for LAN debugging

First confirm that Shadowrocket connects manually on the device providing the service. Then enable only the required LAN access setting and record the current network address and corresponding Proxy port. On another device in the same controlled network, enter that address, port and the correct HTTP or SOCKS5 type, then access one test target. If it fails, check in order whether both devices are truly on the same network, whether local-network permission is granted, whether the router isolates devices and whether the port matches.

If the other device can connect to the port but the target request fails, return to Shadowrocket Log and check whether the request arrived, which Rule matched and which policy was used. If Log has no request at that time, the issue is more likely the LAN path or an incorrect entry. If the request appears but later times out, continue with DNS, server and rule checks. When testing is complete, disable LAN listening if it is no longer needed and remove the temporary Proxy setting from the other device.

When not to change Proxy ports

When Subscribe cannot update, a server Ping times out, a DOMAIN-SUFFIX matches incorrectly, On Demand does not trigger or DNS resolution fails, the local Proxy port is usually not the first item to check. Port settings affect apps connecting through that entry; they do not fix every network issue. First confirm that the failing scenario actually uses a local HTTP or SOCKS5 entry before changing it.

If you simply want to use Shadowrocket normally on iPhone or iPad, prioritize Home connection, Global Routing, Config and actual access verification. Proxy ports are an advanced setting for a clear manual-proxy requirement. Keeping the current working value is usually safer than trying random numbers. If you must change it, record the original and decide whether to keep the new value after verification.

Chapter 08

Config maintenance: rule order, backups and a complete troubleshooting workflow

The scope of Config

Config organizes General settings, Rule entries, proxy groups and other connection behavior. It determines how requests are classified and sent to PROXY, DIRECT or REJECT, but it does not correct incorrect server details. Maintain separate checks for “can the server connect?” and “does the rule choose the expected policy?” First confirm the current server in Proxy mode, then return to Config mode to inspect Rule entries. If Proxy already fails, changing DOMAIN-SUFFIX or GEOIP has no diagnostic value.

Rules match from top to bottom. DOMAIN is suited to an exact domain, DOMAIN-SUFFIX covers a suffix and its subdomains, DOMAIN-KEYWORD matches keywords in a domain, USER-AGENT matches request characteristics, GEOIP uses address location and IP-CIDR or IP-CIDR6 matches an address range. Broader rules are more likely to intercept requests early, so specific rules generally belong before broad ones, with FINAL at the end as the fallback.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

The example demonstrates keywords and order; do not overwrite an existing Config with it. The addresses are for documentation, so write actual rules based on your own targets and service details. Note that DOMAIN-SUFFIX,example.com,PROXY comes before the broader DOMAIN-KEYWORD,example,DIRECT, so the suffix uses PROXY first. If the order is reversed, the keyword rule may match early and change the result. This is why Log review must record which rule matched.

How Config, Subscribe and manual entries relate

The user's existing Subscribe provides the relevant server entries, while Config describes rules and policies. They can refer to each other but are not the same content. After a Subscribe update, entry names, order or availability may change; if Config refers to a particular name, confirm that it still exists. A manually added Add Server entry depends on the protocol parameters entered by the user. Whatever the source, check the protocol, address, port and required fields before testing.

Do not rewrite the only working Config extensively. First create a test copy, change one related group of rules at a time and retain the original for rollback. If the configuration comes from a source you selected and trust, record its update time and the location of local edits so the next update does not overwrite them without notice. This site explains how to import and maintain Shadowrocket configurations; it does not provide server details or Subscribe content.

Restore gradually from a minimal configuration

When a complex Config is difficult to diagnose, copy it as a test configuration and keep only the necessary General items, a few clear rules and FINAL. Verify one DOMAIN rule first, then add DOMAIN-SUFFIX, followed by GEOIP or address-range rules. Reconnect and check Log after each group. This identifies which rule group, remote resource or General setting introduced the issue instead of randomly moving entries among hundreds of rules.

If the minimal configuration works but the original fails, compare DNS, Rule order, proxy-group references and duplicate sections. If the minimal configuration also fails, return to Proxy to verify the server, then use Direct to verify the local network. The complete process should always move from environment to connection, connection to configuration and configuration to one target; do not reverse it by focusing only on the final page.

Complete troubleshooting order

1. Confirm the local network: In Direct, access several unrelated targets to determine whether Wi‑Fi or cellular has basic connectivity.
2. Confirm the server: Switch to Proxy, keep one server fixed, and cross-check with Ping, Connectivity Test and an actual request.
3. Confirm Config: Switch back to Config and check which Rule and final policy matched the target request.
4. Confirm DNS: If the domain cannot be resolved, establish a baseline with the system path, then inspect overrides in Config.
5. Confirm automatic triggers: After manual connection is stable, enable On Demand and test a network switch.
6. Confirm extended features: Check Widget, iCloud sync and Proxy ports last so auxiliary features do not interfere with the main diagnosis.

If these steps do not identify the issue, use the FAQ and look under “Rules and troubleshooting” for the specific symptom. When reporting a problem, provide the minimal reproduction conditions, failure stage and a redacted Log; do not publish server credentials. For first-time users, return to the quick-start tutorial and verify the Add Server, Subscribe, Global Routing and connection-verification workflow. This guide explains setting details; it does not replace the initial setup sequence.

Final checks after maintenance

After a major change, check the current server in Home, Global Routing, Config, On Demand, DNS, Widget and the local Proxy ports, confirming that temporary test values have been restored. Keep a verified copy of Config and use clear names to distinguish production and test configurations. After updating Subscribe or importing data through Import from Cloud JSON, recheck references instead of assuming old names remain unchanged.

Shadowrocket app updates are provided through the App Store. For iPhone, iPad and other Apple devices listed in the store compatibility section, system requirements are as listed on the App Store product page. To recheck the purchase, restore a previous purchase or review device details, use the App Store download guide on this site to open the product page. The goal of maintenance is for every parameter to have a clear purpose, be reproducible and be reversible when problems occur—not to accumulate unexplained switches and rules.