Use the labels and options currently shown in the app; change one variable at a time.
Settings features and the Config file may both affect connections. Before looking for an option, identify whether you’re changing a global preference, the active configuration, or a system permission. Similar names don’t necessarily mean settings belong to the same layer. App navigation may change; the English names below help you locate options without relying on fixed menu positions.
DNS: Distinguish Resolution Failures from Connection Failures
DNS resolves domain names to addresses needed for connections. Check DNS-related options in Settings and the [General] section of the active Config for settings such as dns-server. Changing one without checking the other may leave a relevant setting untouched. During troubleshooting, keep the original value and determine whether the domain fails to resolve, resolves to an unexpected address, or resolves correctly but still can’t connect before making changes.
For example, dns-server = system is one way to configure the app to use system DNS settings; it is not a recommendation for every network. Changing DNS can affect IP rule matching and the actual connection target, but it can’t fix server authentication errors. Make a new request after testing and account for existing DNS cache. One successful request doesn’t mean all domains are working again.
Test Method: Know What Connectivity Test Checks
Find Test Method in Settings, read the descriptions of the available options, and choose a test method. If it requires a target address, check that the target itself is reachable. A port-level response is not the same as completing an app-level request, so results from different methods are not directly comparable. After changing the method, return to Home, run Connectivity Test again, and verify access to the same target directly.
Test results are intended to help narrow down options and locate problems; they don’t represent sustained throughput or the experience of every request. If a test fails but normal use works, check the method and target before changing all server details.
Today Widget: Quick Access and System Requirements
Today Widget provides quick viewing or controls in supported system widget locations. First check related options in Settings, then see whether the widget can be added from the system’s widget editor. Available forms depend on the device’s system and the features currently supported by the app. Don’t assume a particular widget style is available on every device.
Quick access still depends on saved servers and configurations, as well as connection permissions. After tapping the widget, check the actual status on Home, especially after restoring data or before completing the app’s initial setup. A widget is not a separate source of connection settings and does not replace checking the current SERVER.
iCloud: Handle Data Sync and Restoring Purchases Separately
To keep settings across devices, check the iCloud sync option in Settings and make sure the system allows Shadowrocket to use iCloud. Back up important configurations first and compare the existing content on both devices. Sync is not a versioned archive you can always roll back. Verify the actual entries after syncing; an enabled switch alone does not confirm that sync completed.
App Store purchase history restores your eligibility to get the app; iCloud syncs app data when supported. These are separate processes. After moving to a new device, even if the app is installed, check server details, the selected Config, and VPN authorization. Check the in-app description for sync scope. Server credentials and subscription content may be sensitive, so verify the signed-in account and device access permissions before use.
Diagnostics: Keep Context Before Collecting Diagnostic Data
When an issue occurs, find Diagnostics in Settings and use the diagnostic or logging options provided by the app. Note when the issue occurred, the network, Global Routing mode, selected server, and failed target, then reproduce the issue once. This context helps distinguish DNS, authentication, transport, and rule-matching problems and is more useful than an isolated error message.
Before sharing records, check for domains, IP addresses, subscription URLs, authentication details, and personal browsing information. Remove anything sensitive that isn’t needed. A failed request in the log does not prove that all connections are unavailable; consider the time it occurred and repeat the test with the same target. After troubleshooting, restore any temporary diagnostic settings to avoid keeping unnecessary records.