Shadowrocket
Settings Guide

Shadowrocket's behavior is not controlled by a single switch in Settings. System network permissions, the selected server, Global Routing, the active Config, and the server's protocol parameters all play a part. If changing a setting has no apparent effect, first identify which layer you're observing instead of adding more changes. This guide assumes you already have your own subscription or server details. Get subscription links from your service provider, then verify that the selected server and Config are correct after importing them.

Initial State Does Not Mean One Universal Default

“Default value” can refer to three different things: the initial state after installing the app, a value explicitly set in an imported Config, or an older value restored from a device backup or sync. These may differ. The interface may also change with app updates, so this guide does not present unverified port numbers, test addresses, or timeouts as fixed factory defaults. When checking a setting, record both what the current interface shows and what the active Config contains. Don't infer hidden values from someone else's screenshot.

Before making changes, keep a copy of the current Config and note Global Routing, the selected server, the network type, and the issue you're investigating. Describe something reproducible, such as “this domain fails to load on the first try over the current Wi-Fi,” rather than “the network is slow.” Keep the server, network, and destination the same while changing one relevant setting. If things get worse, you can return to a known starting point instead of guessing which switches were previously enabled.

Three Modes Determine Whether Rules Apply

In Global Routing, Config processes requests according to the active Config; Proxy routes requests primarily through the proxy; and Direct connects primarily without a proxy. These modes are useful for comparison during troubleshooting, but they do not guarantee that a destination is reachable. System-reserved traffic, app-specific behavior, and server availability still matter. In particular, testing a rule change while using Proxy does not tell you whether the rules in Config are ordered correctly.

For everyday use, the recommended choice isn't to switch to Proxy across the board, but to use Config with an understanding of its rules. You can temporarily switch modes while troubleshooting, then restore your original selection afterward. Existing long-lived connections may not reconnect immediately, so start a new request; if needed, disconnect and reconnect at an appropriate time. Avoid switching repeatedly during a call, file upload, or other task that can't be interrupted, or you may mistake test-related disruption for a service issue.

Treat the Rule File as a Separate Input

This snippet illustrates processing order. It is not a complete, usable Config and does not create a server. PROXY, DIRECT, and REJECT are rule policies; don't confuse them with the Proxy and Direct interface terms. The example domains are for illustration only. Rules are evaluated from top to bottom, and FINAL should be the last-resort rule at the end. If you move it higher, later rules may never get a chance to match. Before editing, confirm you're changing the active file, not a backup with the same name.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

Compare the expected behavior with the actual request record. If a domain is expected to use PROXY, check the destination domain, matched rule, and final policy in the request log instead of relying on the connection switch on the Home screen. If the rule depends on the resolved address, also check the DNS section. For purchase and installation questions, see the Genuine App Verification Guide. The app's one-time purchase is not a service plan; changing settings cannot replace valid connection details from your service provider.

DNS resolves a domain name to an address needed for a connection. A successful lookup doesn't mean the destination is reachable, and a failed lookup doesn't necessarily mean the server is at fault. A request typically involves a DNS lookup, rule evaluation, connection setup, and application-layer communication; any of these can fail. When checking DNS, write down the full destination domain and distinguish a page error in the browser from a resolution error in Shadowrocket's logs. Don't lump certificate errors, connection refusals, and response timeouts together as DNS problems.

Where DNS Values Come From

Understand DNS-related settings in the app alongside the resolver configuration in Config. If the file specifies a resolver, changing DNS on the system's Wi-Fi settings page may not affect resolution inside the current tunnel. Conversely, if the Config doesn't specify an option, don't assume the app uses a particular public resolver. First check whether the active file contains relevant entries, then note what Settings shows. When reverting a test, be clear about which layer you're undoing.

Using the system resolver is often a useful starting point for troubleshooting because it provides a comparison with the device's current network behavior; it isn't a performance recommendation for every network. Internal domains on corporate, campus, or home networks may only resolve through that network's own resolver. Replacing it with an external address can break access to internal names. If your current Config came from a service provider, understand its DNS setup before overriding it. Avoid combining settings whose effects you can't explain.

This snippet shows only how to declare the system resolver in a Config. It doesn't mean you can remove the rest of the file, and it may not apply to every type of request. Keep a copy of the existing file before editing, and check whether the same key already appears in the section to avoid duplicate entries and confusion. For advanced parameters not confirmed in the current interface or file documentation, leave them unchanged rather than adding keys based on similar-looking names.

[General]
dns-server = system

IPv4, IPv6, and Domain Rules

A domain can resolve to an IPv4 address, an IPv6 address, or both. Having an IPv6 address on your device doesn't mean the full path between the proxy server, destination, and current network supports IPv6 in the same way. If a destination fails only on a particular network, compare the address family in the DNS results with the subsequent connection error before changing related settings. Don't treat disabling IPv6 as a universal optimization: it changes other connection paths and may hide a routing or server-parameter issue.

Rules such as DOMAIN and DOMAIN-SUFFIX match domains directly, while IP-CIDR and GEOIP involve address-based matching. Changes in DNS results can affect which address-based rules match. If the same website uses a different policy, check the domain, resolved address, and rule order together. If the Config uses a specific resolution or mapping mechanism, interpret the address shown in the logs in that context; its appearance alone doesn't prove which path the request took.

Caching and Repeatable Tests

A page refresh immediately after a DNS change may still use an old result. The system, app, and webpage can all cache data or reuse existing connections. Start a new request to a specific destination and check for a new DNS lookup in the logs. If needed, reconnect and reopen the destination app. Don't change several switches just to clear caches: even if the issue goes away temporarily, you won't know whether the cause was the resolver, a new connection, or a change in the destination's cache.

Use a consistent troubleshooting sequence: retry the same destination, check for resolution errors, compare the current network with another known-working network, check DNS entries in the Config, change only the resolver, then reconnect and test again. Record the result at each step. If only internal domains fail, check for local DNS requirements first. If all domains fail, check whether the current network requires a sign-in or authentication. Changing DNS won't provide a useful comparison while the network itself is unavailable.

For encrypted DNS, also consider how the resolver's address is found, whether its connection follows the current policy, and whether certificate validation succeeds. Multiple resolver addresses don't automatically make lookups faster or guarantee identical results. Choose settings that are stable on the current network, have an understandable connection path, and can be reverted. Once verified, keep only the necessary changes and note why they were made so you can reassess them when you switch networks.

On Demand triggers an on-demand connection based on conditions the system can recognize. It controls when a connection attempt starts; it doesn't determine the final policy for a domain or keep the app in the foreground. This distinction matters: if On Demand appears to trigger but a destination still won't open, the issue may be DNS, the server, or a rule. If a manual connection works but the app doesn't connect automatically after a network change, focus on the conditions or system configuration.

Establish a Manual Connection Baseline First

Start by disabling automation and confirming that a manual connection works reliably. Make sure you've approved the VPN configuration when prompted by the system, the selected server is valid, and a target request works under the expected policy. Then enable On Demand. Otherwise, you may have problems with both the manual and automatic paths and won't know whether the failure is at the trigger or connection stage. The exact setup location and available conditions depend on the current app interface; don't assume options from an older interface are available on every device.

Read the current state from your device, especially if you've restored a system backup or already had a VPN configuration. Reopening the app doesn't mean the system's saved on-demand behavior matches a fresh installation. Before changing anything, note whether On Demand is enabled, the order of existing conditions, and the networks they apply to. For a temporary test, preserve the conditions but pause the related automatic behavior. Don't delete the entire configuration and lose the details needed to restore workplace network rules.

If the current interface lets you set conditions by Wi-Fi, cellular network, or specific network name, start with one condition that's easy to verify. Don't add a long list of exceptions at once. Check network names against what the device actually displays, including spelling, spaces, and capitalization. Networks with the same name may still have different environments. A network name is just an input condition, not proof that the network is trusted. Follow the relevant access rules for internal resources rather than using automation as a substitute for access management.

Automatic Reconnection and Manual Disconnects

After you manually turn off a connection, the system may try again when a new network request occurs if the On Demand conditions are still met. Check whether you need to pause On Demand instead of repeatedly tapping the connection switch. If you need to stay disconnected temporarily, explicitly stop the automatic trigger and check the system's VPN status. Restore your original settings after testing so you don't forget to re-enable automatic connections. Record this behavior separately from retries following a failed server connection.

A network transition isn't instantaneous. The device may disconnect from Wi-Fi, switch to cellular, then perform new DNS lookups and connections. Existing long-lived connections may drop, while new requests use the new network path. Test whether a new request works after the switch, rather than just watching for an icon to flash. Allow time for the connection to establish and avoid switching networks repeatedly within a few seconds. Frequent changes add variables and fill the logs with failures that are hard to correlate.

Build a Test Matrix for Different Networks

Test three scenarios separately: connect manually on the current network, connect automatically after switching from another network, and manually disconnect with automatic behavior temporarily paused. For each test, record the trigger condition, system status, and result of an actual request. If only one Wi-Fi network fails, check whether it requires a sign-in page. Network authentication can interact with automatic connections; complete network access first, then test again. Don't change protocol parameters unnecessarily.

On a managed device, other network policies or configuration restrictions may be in effect. Check the active VPN configuration in system settings and review any management requirements before blaming the app's conditions. Don't repeatedly delete system configurations to troubleshoot: this could remove permissions, on-demand conditions, and existing settings at the same time. Pause automatic behavior, keep a record, and test the manual connection separately. Reauthorize through the system only if the configuration is clearly invalid.

The right everyday setting depends on how you use the app. If you want explicit control over when to connect, manual operation is easier to understand. If you want connections triggered by network conditions, enable On Demand one condition at a time. Don't pile on unexplained conditions just to make the app appear “always connected.” After setup, lock and wake the device, switch networks once, and make a new request to verify the full connection lifecycle. To review the initial authorization and connection sequence, return to the Quick Start Guide.

Ping, connection tests, and loading a real webpage are different things. A test may measure the server's response, whether a port accepts a connection, or access to a test destination through a specified route. Its exact meaning depends on the selected test method. A low time doesn't prove that a website will load quickly, and a timeout alone doesn't prove the server is completely unavailable. Before comparing results, check the test type, destination, and network conditions to make sure you're comparing like with like.

Test Method and Measurement Scope

A test that checks only basic network responsiveness may not verify application-protocol authentication or subsequent data transfer. An open port doesn't mean the password, TLS, or SNI settings are correct. A test that accesses a destination through the full proxy path covers more stages, but can also be affected by the test site's own availability. Use a basic test to check whether an address or port is reachable, then verify the full path with an actual request. Don't take a passing first step as proof that all settings are correct.

Use the current interface to check the initial values for the test destination and timeout. Existing Configs and saved settings may retain older values, so don't rank results from different devices by the number alone. Keep the app's current working settings as a baseline. If you need a different test destination, choose one whose purpose you understand and that is reachable in your environment. Change either the destination or timeout, not both at once, so you don't mistake a changed measurement method for a change in server performance.

Choose a test destination that's stable, returns simple responses, and suits what you're trying to verify. Results can be affected by extra conditions if the destination requires sign-in, redirects, applies rate limits, or returns different content on different networks. Don't test a large number of servers repeatedly in quick succession and mistake brief queuing or rate limiting for a persistent failure. If you have a subscription, compare only the few servers you actually use; there's no need for every row in a list to show similar numbers.

A shorter timeout isn't necessarily more accurate

If the wait period is too short, the first DNS lookup, connection setup, and encrypted handshake may not finish before the test is marked as timed out. A longer timeout, on the other hand, means slower feedback when something fails. Keep the current value as a baseline and run a small number of tests to see whether results are consistent before adjusting it for your needs. Increasing the timeout only extends the wait; it won't fix an incorrect address or failed authentication. If results vary widely, check network load and transitions rather than immediately choosing the lowest result.

Latency measures the time for a particular interaction. Throughput, packet loss, congestion, and the destination server's response also affect how a connection feels. A small page may load while a large file transfer fails, or text messages may work while video calls are unstable; these need tests closer to the actual task. Compare using the same device, network, approximate time, and test destination, then confirm with a real task. Results from different times or test methods are records of different conditions, not direct comparisons.

Trace an Unexpected Result Back to Its Parameters

If only one server fails, first check its address, port, protocol, and the details from your service provider. If everything fails on the same network, check network access and whether the test destination is available. If a basic test succeeds but the actual connection fails, check the password, TLS, SNI, system time, and certificate validation. Don't disable certificate validation just to get a passing result. That changes the security boundary and doesn't prove the original parameters were correct. Fix them using the correct information from your service provider.

Keep data usage and device activity in mind when testing. Repeated tests create extra connections and count toward cellular data usage. Results may differ when background sync or downloads are active, so record whether other data transfers were in progress. Run a few tests under relatively stable conditions and look at the range of results and failure patterns. Don't turn an occasional low value into a long-term conclusion, or treat a test ranking as a guarantee of server quality.

For related troubleshooting, see the Server Timeout Troubleshooting Checklist. To understand how test results relate to real-world performance, read Choosing by Latency, Region, and Protocol. Keep measurement conditions consistent, use the numbers as clues, and verify with real requests. If server parameters change, establish a new baseline instead of relying on old test results.

Log helps you investigate connection errors, while Data shows related data and request information. The exact location and fields depend on the current interface. The goal isn't to make every number keep growing, but to link a particular failure with its destination, policy, and failure stage. Start with a specific question, then check the relevant records. Browsing a large number of historical entries can make it easy to mistake a background request from another app for the cause of a current page failure.

Build a Timeline from One Request

Before you start, note the local time, network type, Global Routing mode, active Config, and selected server. Reproduce the issue once—for example, by opening a specific page—then check the records for that time. First confirm whether the destination domain appears, whether it resolved, which rule matched, which policy was used, and what error occurred. Apps may contact several domains at once, so a successful request to the page's main domain doesn't mean every resource loaded successfully.

Don't assume that log levels, logging switches, or retention settings have the same initial values across devices. For everyday use, keep a level of detail that suits your needs and increase it temporarily only when investigating an issue. More detailed logs may require additional storage and processing, and may include more browsing information. After enabling a log option, check that it captured information related to your test; the switch being on isn't enough to complete a diagnosis.

If the current interface lets you clear logs, decide first whether you need to keep the context before and after the failure. Save any necessary information, then create a clean window for reproducing the issue. Don't clear the logs while repeatedly reconnecting, or later retries may obscure the first error. For intermittent issues, a few records around a network transition are often more useful than a single error line, which may only be a downstream effect of an earlier failure.

Interpret Errors by Stage

For a resolution error, start with DNS. For a refused connection, check the destination port and service status. For a timeout, check the network path, test window, and remote response. For a TLS or certificate error, check SNI, system time, and certificate requirements. Keep the original error text where possible; a summary can lose important information about the stage. The same symptom can have different causes. Don't change DNS, ports, and rules all at once just because you see “timeout,” or the next result will be hard to compare.

Rule troubleshooting also means distinguishing the expected match from the actual match. If you expect a domain to use DIRECT but the log shows it matched FINAL, the rule may not match the domain, may be in the wrong order, or the actual request may use a different subdomain. Compare against the real destination instead of adding rules for a guessed domain. For top-to-bottom matching and fallback placement, see Custom Rule Priority, then verify it in the active Config.

Traffic Figures and Logging Limits

Interpret traffic statistics in Data in light of what they measure and the time period covered. The amount recorded by the app may differ from your service provider's billing because of protocol overhead, billing rules, retransmissions, or a statistics reset. Don't read a cumulative figure as your remaining monthly allowance. For usage and billing, follow your service provider's information and note when local statistics began; don't repeatedly reset the counter to guess how you're being billed.

Request logs also have limits. App caches, existing long-lived connections, system behavior, and log levels all affect what's displayed. The absence of a record doesn't prove a request never happened, and a connection entry doesn't necessarily mean the application exchange succeeded. Compare client logs with the destination app's actual result, and reconnect if needed to observe a new request. For encrypted traffic, logs don't reveal the full contents of the application exchange.

After troubleshooting, restore any temporarily increased log level, remove copies containing sensitive information if appropriate, and keep a short summary: the error, the setting changed, how you retested, and whether you restored the original value. Avoid keeping large, unfiltered logs indefinitely or sending your entire Config along with every request record. Useful notes preserve the steps and results, not secrets, so you can repeat the troubleshooting process without exposing old credentials.

A Widget is a shortcut for checking status or opening an action from a system-provided location; it isn't a separate connection service. It depends on the app being configured, system authorization, and when the system refreshes it. Before using one, complete a manual connection in Shadowrocket, then add or configure the Widget. If initial authorization isn't complete, starting an action from the shortcut may still require confirmation in the app or a system prompt. That's separate from whether the server parameters are valid.

Configure the App Before Adding a Shortcut

First decide what you want the Widget to show or do: display the current status, or provide a quick way to open the app and manage the connection. Available Widget sizes, locations, and interactions may vary by device and system; check the add-widget interface on your device. This guide doesn't assume that a particular size, button, or layout is available everywhere. If an option isn't shown, check app and system support instead of repeatedly changing server parameters to find it.

The Widget's initial display isn't the same as the connection's default state. It may show cached or not-yet-loaded content, or information from an earlier session. After adding it, open the main app and confirm the current server and connection status, then check the Widget again. If you can choose what it displays, start with the simplest layout. A delayed update to one item in a more complex layout doesn't mean the whole connection is down, and shouldn't be the sole reason for switching servers automatically.

When arranging your device's Home Screen, consider what information others can see. Server labels may reveal their purpose, organization, or personal details even if they don't include passwords. Use labels without sensitive information and choose a location with shared use and lock-screen visibility in mind. Consider convenience and information exposure together. Check the controls your system actually provides for lock-screen access or display; don't infer them from a screenshot of another device.

Check the Display Refresh Separately from Connection Status

The system controls when Widgets refresh, so displayed information may lag behind the main app. If the two don't match, open Shadowrocket and check the current connection, check the system VPN status, and make an actual request. Don't repeatedly tap the Widget to force a refresh; repeated actions close together may switch the connection on and off and create new failures. If only the text is delayed, treat it as a display issue instead of rebuilding the entire Config.

After using a shortcut, wait for the connection process to finish before checking the result. Server authentication, DNS resolution, and tunnel setup all take time; tapping once doesn't mean the destination is already available. If the action opens the app, check for a system authorization prompt or error, then review the relevant Log entries. Verify the shortcut by making a request to a fixed destination. A changed icon is only a limited status clue, not a complete network test.

Interaction with On Demand

After enabling On Demand, manually disconnecting from a Widget may not keep the connection off. If the trigger conditions are still met, the system may try to reconnect. To pause automatic connections temporarily, handle the On Demand conditions before using the shortcut. Repeatedly disconnecting from the Widget may make it seem like the button isn't working. Record whether the tap performed the action and whether an automatic trigger occurred afterward; treat them as separate steps.

After changing servers, editing a Config, or restoring a backup, recheck what the Widget displays. An old label or status may remain temporarily; it doesn't confirm that new requests still use the old server. Open the main app to confirm the selected item, then make a new request and check its route in the logs. If the app works but the Widget remains out of date, follow the system's steps to remove and re-add the Widget. This addresses the display only; don't delete the in-app Config at the same time.

For everyday use, treat the Widget as a way to reduce the number of steps needed to open the app, and make important changes in the main app. For subscription updates, rule edits, or protocol changes, use the full interface and review any prompts. After troubleshooting, restore your preferred display, use clear labels, and check the system's privacy settings for your situation. A small area that may refresh late is useful as a shortcut, but can't serve as a complete diagnostic tool or proof of connection status.

iCloud features save or sync app data where supported, but enabling iCloud doesn't guarantee that all servers, Configs, history, and system permissions are fully synced. Check the current interface and verify what actually appears after recovery. Purchase history, app data sync, and system VPN configuration are separate. Restoring a purchased app from the App Store doesn't mean connection details have been restored; seeing app data doesn't mean you can skip system permission prompts.

Check Sync Scope and Keep a Separate Copy

Before syncing, check the iCloud account signed in on the device, whether the system allows the app to use iCloud, and the available cloud storage and network connection. Don't confuse the account used for App Store purchases with the account used for iCloud data; they have different roles. Being able to install the app doesn't prove that the same account is being used for sync. Test the sync path first with an easy-to-identify Config label that contains no sensitive information, then handle important data. Don't rely on an unverified full restore from the outset.

Check the current device to see whether sync is on and which items are included; this guide doesn't assume a universal default. Before enabling it, keep a separate Config backup that you can access, and verify that the copy can be opened. Backups may contain server credentials, so choose their location and access permissions carefully. Not every file stored on the device is an independent backup: if it's the same file you're editing, it can't restore the previous version after an accidental change.

Choose one primary editing device. Editing a Config with the same name on multiple devices at once may result in differences, delays, or conflicts, depending on the sync mechanism. Don't assume that the device where you opened the app last will have the correct version. After editing on one device, wait for the other to show the corresponding content, then compare important rules. Matching filenames don't prove that the rules, server references, or changes are identical.

Restore in Stages After Switching Devices

Check recovery in four stages: get the purchased app from the App Store, confirm that app data appears, verify the current server and Config, then complete connection authorization when prompted by the system. Verify each stage separately. If the data has synced but the connection fails, check parameters and permissions instead of immediately deleting cloud data and starting over. For restoring purchases and compatibility, see Switching Devices and Reinstalling. Check the App Store page for system requirements.

After restoring a subscription list, confirm that it updates successfully and that the server labels and parameters match the information currently provided by your service provider. Sync may restore an old list even if the subscription content has changed. Get subscription links from your service provider and protect them as credentials; don't put them in public labels, screenshots, or shared documents. If one server is missing a particular parameter, check its source instead of repeatedly toggling iCloud to fix protocol details.

Troubleshooting Sync Differences

If two devices show different content, first check the account, the app's iCloud permission, the network, and available storage. Make sure you're comparing the same item. Wait a reasonable time for sync, reopen the app, and check for errors or conflict prompts. Don't keep editing, deleting, and recreating same-named files on both devices; that makes the source of differences harder to identify. Pause edits, save a copy from each device, and decide which version to keep based on its contents, not its filename.

When an offline device reconnects, its old content may rejoin the sync. Before restoring an important Config, identify devices that still have an older copy and check what happens when they come online. Don't assume that deleting data on one device only affects that device unless the current interface clearly says so. For sensitive data, check separately whether you're deleting a local file or a cloud copy; clearing one screen may not remove every copy.

For everyday use, sync for convenience and keep an independent backup for recovery. Include necessary Configs and recovery instructions in the backup, leave out unrelated old logs, and note which permissions need to be approved again on a new device. Test recovery when you can afford an interruption, then remove temporary copies after confirming it worked. For iPad layouts and Config migration, see Using Shadowrocket on iPad. Always verify the actual recovery result on each device.

When discussing Proxy ports, first distinguish the remote server port from a local proxy listening port. The port entered in Add Server connects to the remote service provided by your service provider. A local listening port accepts connections using the corresponding proxy method. They are different fields and don't need to use the same number. Changing a local port doesn't change where the remote service listens, and changing the remote port won't resolve a conflict on the device.

Match the Port to the Protocol

HTTP and SOCKS5 are different proxy methods; the client's requests must match what the receiving end supports. A port number alone isn't enough to make a connection: the address, protocol, and any required authentication must also be correct. Check the current Settings interface for whether the feature is available, whether LAN access is allowed, and the names of the relevant fields. If the interface doesn't provide a listening feature, don't assume Shadowrocket has the same option just because another app does.

Read the local port's initial value from the interface on your device instead of assuming a commonly used number is a fixed app default. Leave it unchanged if you don't need to connect to it. If you do, choose a valid, unused port and enter exactly the same value on the requesting device. After changing it, verify that it is listening; don't just check that the setting was saved. If the port is in use, find out what uses it and choose another rather than masking a persistent conflict by repeatedly restarting.

Loopback and LAN addresses are also different. A loopback address on a device points back to that device; another device can't use its own loopback address to reach it. LAN access requires network reachability, the correct device address, and an explicitly permitted listening scope. Device addresses may change when the network changes, so a working setting may stop working after you switch networks. Don't just copy an old address. Confirm that both devices are on networks that can communicate, then test the port.

Listening Scope Is an Access Boundary

If the current feature lets you expose a listener to the LAN, treat it as a new access point, not a performance switch. Enable it only when needed, and check the available authentication and access controls. Don't broaden the listening scope on public networks; close temporary access when you're done. Whether other devices can connect depends on network isolation and system behavior. A failed test doesn't prove the listener wasn't exposed, so assess the risk based on the configured scope itself.

First confirm that the local connection works. Then check reachability from the requesting device to the listening address, verify the proxy type and authentication, and check whether the request appears in the logs. If local access already fails, changing the listening port is unlikely to help. If local access works but the request doesn't appear at all, check the address, port, and network isolation first. If the request appears but returns an error, use Log to distinguish authentication, DNS, rule, and remote connection issues. Keep the troubleshooting steps in order.

Wrap Up with a Minimal Change Log

After changing any setting in this guide, complete the loop: make a new request to the destination, check the policy actually used, look for a new error, and confirm that other common tasks still work. After changing a port or listening scope, also make sure any temporary access point is closed as planned. Don't record only “fixed.” Keep the old and new values along with the conditions used to verify them, so you can decide whether to revert when the network changes instead of adding more exceptions.

The format below is for personal troubleshooting notes, not an importable Config. Don't include passwords, subscription links, or keys. For WireGuard field meanings, see the WireGuard Parameters Guide. Identify whether a parameter belongs to the server protocol, tunnel address, or local listener before changing it. This helps keep similarly named settings with different roles out of the same test.

Target: example.com
Network: current Wi-Fi
Global Routing：Config
Change: one setting
Original value: recorded on this device before the change
Verification: make a new request and check Log
Rollback: undo this change and test again

If you still can't identify the issue, return to a minimal baseline: a valid existing server, a clear Config, a working network, required system authorization, and as few custom settings as possible. Then add conditions one layer at a time—DNS, connection, rules, and app behavior—instead of resetting all data. For purchase questions, see Pricing and One-Time Purchase. For your first connection, return to the Quick Start Guide. This page explains settings and verification; it doesn't provide connection service or replace confirmation of server status and parameters from your service provider.