Shadowrocket Complete User Guide

01 / GET THE APP

App Store Purchase and Compatibility

Verify the app before purchasing

Shadowrocket is a paid client for Apple platforms, available through the App Store. Before purchasing, check the product page rather than relying on the name in search results. Confirm the developer is Shadow Launch Technology Limited, check that the icon matches the official icon in this site’s header, and verify that the product link includes app ID 932747118. Together, these details identify the app; a similar name alone is not enough. For step-by-step instructions, see the genuine app verification guide.

The App Store page also provides details to check on pricing, compatibility, and purchase eligibility. Confirm that your device appears in the compatibility information, then review the price shown. System requirements and purchase eligibility are as listed on the App Store page. This guide focuses on iPhone and iPad. Shadowrocket is also available on the same App Store listing for Mac and Apple TV, but button locations on mobile devices may differ from those on other devices.

Purchase the client separately from connection details

A one-time client purchase is not a service plan. Purchasing the app gives you the right to use the client; it does not provide a server. To connect, you need your own server details or subscription, which you can get from your service provider. Before you begin, confirm the type of information you have, the supported protocol, and whether the details are still valid. A server address alone is usually not enough: the port, credentials, and transport settings must also match.

Prices vary by App Store storefront and are displayed in local currency; the final amount appears on the purchase confirmation screen. The client price does not cover network service, and examples in this guide do not establish your actual connection requirements. This site provides the official guide, not server services. If a server has expired, credentials have changed, or the service is under maintenance, check the details from your existing provider. Buying the app again will not fix these issues.

What to do after installation

After completing your App Store purchase, wait for the app to finish downloading, then open it from your device’s Home Screen. If the icon is still waiting, first check your network connection, available storage, and any App Store messages. Don’t troubleshoot proxy settings yet. At this point, the client has not started handling network connections; installation and connection issues are separate. For help with purchase and download status, follow the App Store download steps.

Before opening the app, organize the details you already have and identify whether each item is a server link, subscription URL, or configuration file. A server entry describes one connection; a subscription provides and maintains a group of servers; a configuration file primarily contains rules and related settings. These may be provided as text or links, but they serve different purposes. Don’t paste a subscription URL into a server address field or treat a configuration file as a subscription update just because both can be copied.

What purchase history restores—and what it doesn’t

When switching devices, first check your App Store purchase history and look for the app using the Apple Account used for the original purchase. Redownload availability and Family Sharing eligibility are as listed on the App Store page. If the store still shows a price, check your account and purchased items before paying again. App access and data saved in the client are separate: restoring a purchase does not restore servers or rules.

Plan how to transfer your configuration while your old device is still available. Note the subscription and configuration names in use, along with any essential settings, and keep the original details safe. Treat subscription URLs and passwords as sensitive; don’t put them in public notes or screenshots. You’re ready to move on when the app opens and you’ve verified that it’s the correct app. Next, grant the system’s network permission and import your existing details.

02 / INITIAL SETUP

First Launch and System Permissions

Allowing Shadowrocket to add a VPN configuration

When you first connect, your device may ask whether Shadowrocket can add a VPN configuration. This system permission allows the client to handle network requests from your device; it is not a server account or proof that a subscription is active. Confirm the prompt comes from the client you’re using, then authenticate as requested by the system. Granting permission only allows the network configuration to be created. You still need to check whether the remote server is reachable.

If you declined the prompt, try connecting again in the client and see whether it reappears. If needed, check the VPN-related settings on your device for the configuration status. The name and location of these settings may vary by system; follow what you see on your device. Don’t reset all network settings just to resolve a permission prompt. First determine whether permission is still needed or whether it was granted and the connection is failing for another reason.

Use Home to identify the controls

On Home, locate the connection switch, Global Routing, Connectivity Test, and SERVER list. The switch starts or stops the current connection; Global Routing determines how requests are routed; the SERVER list contains added servers; and Connectivity Test helps assess connectivity. Each has a separate role. A server appearing in the list doesn’t mean you’re connected, and a test result doesn’t confirm that rules are behaving as expected.

If the SERVER list is empty, import your details as described in the next chapter instead of repeatedly toggling the connection switch. If entries are already there, check their names, types, and default selection so you don’t mistake old details for a new import. The layout may vary by device and app updates; this guide uses interface labels rather than fixed screen coordinates. For an introduction to these areas, see First launch and the Home screen.

Grant additional permissions only when needed

When you use Scan QR Code, camera permission lets the app read the code. Selecting a QR code from Photos may prompt for photo access separately. Grant only the permission needed for the action. Manually entering server details and scanning a QR code are separate options; denying camera access does not mean network permission was denied. If scanning fails, check whether camera access is disabled, the image is unclear, or the current entry point can’t read that type of content.

QR codes and clipboard contents may contain complete credentials. Before importing, confirm that the information comes from your existing service details. Review the import preview before saving. Don’t import arbitrary images, and don’t publicly share a page containing a full QR code. If copying doesn’t open an import prompt, return to the appropriate entry point for that information type. Don’t repeatedly copy different content just to trigger a prompt; that can make it unclear where the imported details came from.

Rule out system-level conflicts before connecting

If another VPN configuration is active on your device, first understand what it is for and whether it is managed. When testing Shadowrocket, avoid having multiple configurations handle network traffic at the same time; this can cause system state to change unpredictably. On an organization-managed device, policies may restrict configurations and permissions. Follow the device management requirements if a control is unavailable or the system displays a restriction, rather than repeatedly rebuilding the client configuration.

A public Wi-Fi network may require you to sign in or accept terms before connecting. Stop the client and check that the device’s regular connection works first, then configure Shadowrocket. Keep the system clock accurate; an incorrect time can affect certificate checks for secure connections. After setup, note which permissions you’ve granted and which you haven’t needed. That will help you distinguish permission issues from server problems later.

03 / IMPORT

Servers, Subscribe, and Protocol Settings

Choose the right import method

Enter a single server manually through Add Server, or import it using a sharing format supported by the client. A group of servers that needs ongoing updates is usually managed through Subscribe. Identify the type of information you received before choosing an option. Get your subscription from your service provider; the full URL may contain credentials. When pasting it, check the beginning, end, and line breaks so punctuation added by a messaging app doesn’t become part of the URL.

After saving, return to Home and check which group contains the new entry, whether its name makes sense, and whether its server type matches the original details. An entry appearing means the client read the information; it doesn’t mean the remote credentials are valid. If the import produces no entries, check whether the response contains server details the client can recognize, rather than a sign-in page or message. Don’t create multiple subscriptions with the same name to hide a failed update.

Match protocol settings field by field

Protocol names determine what each field means. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard don’t share the same setup fields. Select the correct type first, then enter the address, port, and protocol-specific credentials from your original details. The name is only a local label; renaming it won’t fix a connection. Ports and credentials are used for communication, so check them exactly, including spaces and capitalization introduced during copying.

Connections using TLS may also require fields such as Server Name, which may not match the connection address exactly. With certain transports, fields such as Path and Host must also match the server. Don’t guess values from field names; check the original details for anything missing. Disabling certificate verification is not a routine fix and weakens checks of the remote server’s identity. First check the name, system time, and whether the details have expired.

Handle subscription updates separately from manual edits

After saving a subscription, update it and check for changes to server count, names, and groups. An update can fail while fetching the URL, accessing the network, or parsing the response; that doesn’t necessarily mean every server is unavailable. Keep the current working list while you check whether the subscription URL changed, renewal is required, or the current network can fetch the content. Don’t immediately delete the whole group: you could lose a useful comparison or interrupt a working connection.

Servers managed by a subscription may be regenerated or overwritten during later updates. If you need to test a field temporarily, record its original value and check how the client handles edits to subscription entries. For a lasting fix, use accurate details from the service provider instead of relying on repeated manual edits after each update. After a successful update, check the default server again; renamed, replaced, or removed entries may affect your selection.

When to add manually, scan, or remove duplicates

Manual entry works well when you have complete details to check field by field; Scan QR Code is useful when you already have a compatible QR code. Scanning is just an import method and doesn’t make a server more available. After scanning, verify the type and key fields before saving and testing. If several entries have similar names, compare their protocols, addresses, and ports. Don’t delete entries based on names alone; different transport settings may intentionally use similar names.

After importing, choose one server with clear source details as your initial test. Don’t add complex rules or change several protocol fields at once. You’re ready to troubleshoot if you can say where the entry came from, which fields you checked, and why it’s the default. A subscription maintains server details; Global Routing and configuration determine how requests are routed. The next chapter explains each separately.

04 / ROUTING

Global Routing and Configuration Files

Understand Config, Proxy, and Direct

In Global Routing, the configuration, proxy, and direct modes are labeled Config, Proxy, and Direct. Config uses the rules in the current configuration to decide where requests go. Proxy handles requests in proxy mode, while Direct handles them directly. Changing modes changes how routing is decided; it doesn’t fix incorrect credentials. If something goes wrong, check the current mode first so you don’t mistake a rule sending traffic directly for a server that isn’t working.

For troubleshooting, you can briefly switch modes for comparison, but note the purpose of each change. If a request works in Proxy but fails in Config, check the rules and policies. If it fails in both, check the server, name resolution, and current network. If a destination is reachable in Direct, that only shows it can be reached over the current direct route. Network conditions vary by destination, so one successful page doesn’t prove that every connection works.

Configuration file sections and their roles

Config manages configuration files, while Config in Global Routing is a routing mode. The names are similar, but they refer to different things. A configuration file may contain sections such as General, Rule, and Host for general settings, rules, and hostname mappings. Before editing, confirm which file is active and save a usable copy. A file appearing in the list doesn’t mean it’s the one used for connections.

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

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

This example illustrates the structure; it isn’t a complete configuration for every network. example.com is a sample domain; PROXY indicates a proxy policy, and DIRECT indicates a direct policy. The actual destination for proxy traffic also depends on the selected server or a defined policy. Keep settings that have already been verified in the original configuration and change only what you need to test. Don’t combine whole files from different sources, which can duplicate sections or leave policies without their intended references.

Rules are evaluated in order

Rules are generally checked in order, so put specific conditions before broad ones. DOMAIN matches a specific domain; DOMAIN-SUFFIX matches domain suffixes; DOMAIN-KEYWORD matches keywords in a domain. IP-CIDR and IP-CIDR6 apply to address ranges; GEOIP checks an address against a location database. FINAL handles requests that matched no earlier rule and should go at the end. Once an earlier broad rule matches, later, more specific rules won’t have the expected effect.

Domain and address rules rely on different information. Whether a request can be matched by a domain condition depends on the information available to the client. An address’s geographic classification doesn’t necessarily reflect where a service operates. Don’t add a broad keyword rule just because a domain contains a particular word. A page may use several domains; use actual records to add only the conditions you need, one at a time, and keep the change focused.

Verify changes instead of just checking that they saved

After saving, confirm the configuration is still recognized, then make a new request to check which rule matches. A successful save only means the text was stored; whether rules take effect depends on the active file, routing mode, and information available for the request. Existing long-lived connections may continue along their current path, so start a new request to test. If the change causes a problem, revert that set of rules; this is easier to diagnose than adding more conditions one after another.

Maintain configurations and subscriptions separately: subscriptions update server details, while configurations control routing and related behavior. A policy name in a rule must have a corresponding definition; adding more servers won’t fix a missing reference. If you don’t understand a setting, keep a working copy and don’t delete it based on a comment alone. For a specific issue, see Troubleshooting. First note the current file, mode, and target request.

05 / VERIFY

Default Server, Connections, and Testing

Start with a test where the variables are clear

Return to Home and check the default server in the SERVER list. Note which entry the DOT marker points to. Opening an entry’s edit screen is not the same as selecting it as the default; check the selection shown in the list. For your first test, choose one server with a clear source and verified protocol settings. Avoid enabling complex automatic selection conditions yet, so you can tell whether a connection change comes from the network or the selection logic.

Next, check Global Routing and note the current configuration name, then turn on the connection switch. If the system asks to add a VPN configuration, grant permission as described earlier. Wait for the status to settle before testing; don’t rapidly toggle the switch. Repeated reconnections mix the results of multiple attempts and can start another test before the system state has updated. If the system shows an explicit error, save its wording, then stop and classify the issue.

Evaluate test results in separate layers

Connectivity Test helps assess the connection; the test method and target depend on the current client settings. Results reflect the local network, server response, test target, and protocol conditions. A low value doesn’t mean every request will work, and a timeout doesn’t immediately prove that credentials are wrong. Confirm which server is being tested and how, then compare the result with actual access.

Check three layers: the system allows a connection, the client can communicate with the selected server, and the target request returns content through the expected policy. Checking each in order prevents treating an enabled switch as proof of success. After connecting, visit a destination whose expected result you know and check which policy it should use. Then test another type of request to rule out a misleading result caused by a cached page.

Troubleshoot in order: network, settings, then rules

If the connection fails, stop the client first and check whether the device’s regular network works. If it doesn’t, address network sign-in, signal, or routing issues first. If it does, check the default server and protocol settings. An address lookup failure, unreachable port, authentication failure, and certificate validation failure occur at different stages. Use the error message and available records to tell them apart; don’t label every issue a “server timeout.”

Next, use a temporary mode change to isolate rule-related issues. If the same request works in proxy mode but fails in configuration mode, check the active file and matching policy. If it fails in both, check the server details and network conditions. Change one field or mode at a time, then repeat the same request. For a suggested sequence, see Troubleshooting server timeouts. Don’t change every condition at once.

When the connection works but some content doesn’t

If a page loads but images, sign-in, or other resources fail, examine the requests separately. A page may connect to several domains, each matching a different rule, or use a persistent connection. Note the failed resource’s domain, policy, and failure stage before making changes. Adding only the page’s URL to a rule won’t necessarily route every resource the same way. Nor should you permanently route all requests through a single policy without a clear reason.

If only one app has a problem, first compare its requests with those made by a browser to the same destination. Then consider caching, name resolution, and connection reuse. If needed, fully quit the app and try again, keeping a note of the results before and after. For secure connection errors, check the system time and server name first. Don’t bypass identity checks just to make one test pass; that weakens an important connection security boundary.

Finish testing and restore your everyday settings

When testing is done, switch any temporary routing mode back to your usual setting and confirm the default server hasn’t changed. Record the working configuration, test network, and main findings; there’s no need to note fleeting values. A useful conclusion says which request worked, under what conditions, and through which policy—not simply “connection OK.” That gives you a baseline to compare against next time.

For a first connection, use First Connection and Connectivity Test to check for anything you missed. If you need to keep troubleshooting, record only the essentials: server type, mode, error text, and steps to reproduce. Don’t share passwords, subscription URLs, private keys, or complete sharing links. Use the same step-by-step approach when reviewing requests in Data.

06 / OBSERVE

Data: Traffic and Request Analysis

Treat statistics as observations, not conclusions

Data shows traffic and connection information provided by the client; the specific items depend on the interface. An increase in traffic means data passed through the measured scope, not that a request completed or that all traffic went through the same remote server. Conversely, little visible change may be due to caching, a delayed statistics refresh, or a request that hasn’t started. First decide what you’re observing, then interpret the numbers; don’t use totals as a substitute for checking an individual request.

Before reviewing data, confirm the connection is active, the default server is correct, and there aren’t many background tasks running during the test. If photos are syncing while you troubleshoot a single webpage, total traffic won’t tell you much about that action. Narrow the observation period, make one reproducible request, then check for new records. This helps you relate page loading, request activity, and rule matching in sequence.

Trace a request to the policy it uses

If the client provides request logs or connection details, find the entry that matches the time you reproduced the issue, then review any available domain, address, policy, and error information. The details shown may vary by protocol and request type; don’t assume every record includes a full URL or content. Focus on where the request went, which rule matched, and where it stopped, rather than inferring an app’s entire behavior from one record.

In Config mode, compare the expected policy with the actual one. If you expected PROXY but got DIRECT, check earlier rules and the active file. If the policy is correct but the request still fails, check the relevant server and whether the destination is reachable. A rule match only confirms the routing decision; it doesn’t prove the remote service responded correctly. Keeping routing and transport separate helps avoid unnecessary changes.

Distinguish name resolution, connection setup, and data transfer

A domain request typically goes through name resolution, establishes a connection to the selected address, and then exchanges app data. Changing a password won’t help if name resolution fails. If an address is resolved but the connection cannot be established, check the network, port, and server. If the connection is established but a secure handshake fails, check the certificate name, time, and relevant settings. Error messages can differ by stage; read them in context and keep the original wording rather than rewriting them all as the same issue.

If a domain resolves to multiple addresses, don’t assume the configuration is inconsistent. A service may return different results depending on network, time, or location, which can also change how address rules match. Repeat the same request to confirm the behavior, then compare the resolution conditions on the direct and proxy routes. Don’t permanently enter a single observed address in Host without testing it; a fixed address can quickly become unsuitable and cause new problems.

Client statistics may differ from service-side records

Client, device, and service-side statistics may cover different things. They may count different traffic directions, connection overhead, or time periods, so the numbers won’t necessarily match exactly. To investigate unusual usage, compare the same time period, pause obvious background tasks, and review the trend. Don’t treat a brief difference as a billing error or assume one total is a complete record of every app’s usage.

Before resetting statistics, save any findings you need for comparison and check which items the reset affects. Clearing a local display usually won’t change service-side usage records or fix a connection. When troubleshooting, changes tied to a specific request are more useful than repeatedly clearing totals and watching them again. If the client provides multiple statistics views, check their labels and scope before deciding what to use.

Remove sensitive details before sharing records

Request records may include destinations, server addresses, and other identifying information. Before exporting or taking a screenshot, review what’s visible and keep only what’s needed to resolve the issue. Don’t share subscription URL parameters, server passwords, UUIDs, or private keys with the records. Even sharing a QR code may reveal complete connection details; hiding a name doesn’t necessarily hide sensitive information.

When preparing troubleshooting information, include the steps to reproduce the issue, the stage where it occurred, the protocol, and the policy, then quote the error without credentials. Keep a complete copy locally for your own reference and share only the smallest relevant excerpt. If you’ve traced the issue to server settings, check the original details rather than collecting unrelated requests. When finished, return to everyday settings and turn off any extra logging enabled for testing.

07 / SETTINGS

Common Settings and When to Change Them

Identify which layer a setting affects

Settings don’t all control the same thing. Some affect the client globally, some affect connections, and others only change display or testing preferences. Settings on a server’s edit screen may apply to that entry alone. Before changing an option, identify its scope and check whether the configuration file also defines related behavior. Don’t treat a server’s transport setting as a global network setting or assume an option with the same name has the same priority everywhere.

This chapter explains settings by purpose; not every device will show the same options. Interface labels and available settings depend on the current client. If you’re unsure what an option does, note its current value and the specific issue you want to solve, then look up the relevant information. If your connection works, keeping the default behavior is usually easier to maintain than enabling multiple advanced options. Changes without a clear goal are difficult to verify and harder to undo if something goes wrong.

Set up On Demand after manual testing

On Demand triggers connection-related behavior based on conditions. First establish a manual connection and verify a request; otherwise, automatic triggering makes an unresolved issue harder to observe. In the relevant settings, carefully check the enabled state and applicable conditions, then test in a real network environment. An enabled setting doesn’t guarantee the connection will be maintained in every situation; behavior also depends on the system, network, and configuration.

When testing On Demand, check both when it should trigger and when it should not. For example, after switching networks, wait for the system state to settle, then check the connection status and request result. If the connection repeatedly restarts, temporarily turn off On Demand and verify the basic connection manually before reviewing the trigger conditions. Also consider restrictions on managed devices; client conditions and system policies can interact in ways that are difficult to diagnose.

Change DNS only to address a reproducible issue

DNS resolves domains to addresses and may also affect some rule matching. Change the relevant setting only after confirming a resolution issue or unexpected result. Note the original resolution method, test domain, and symptoms, then change one thing at a time. Don’t make switching DNS your first response to every connection problem: a wrong port, expired credentials, or mismatched transport settings won’t be fixed by changing how names are resolved.

In the configuration example, dns-server = system uses system-related resolution settings; it isn’t guaranteed to suit every network. If you use another resolution method, understand its route and requirements. The resolution service itself may depend on a connection that hasn’t been established yet. After changing the setting, make a new request and account for caching when comparing results. Be clear about which method you keep when testing is done; don’t let temporary changes accumulate.

Testing, Timeouts, and Network Changes

Connectivity Test settings determine how a test runs, so changing the method affects whether results can be compared. When comparing servers, use the same method and target rather than ranking results from different test conditions. Set timeouts within reasonable limits: too short can treat a normal but slow response as a failure; too long delays error feedback. Consider the current network before adjusting settings instead of chasing a better-looking result.

If you see a brief issue after switching networks, wait for the system to finish switching, then start a new request. An existing connection may not continue over the new route, and some apps retry automatically. If the problem occurs only during the transition, record it separately from failures that persist on a stable network. Checking On Demand, the default server, and the new network is more useful than resetting every setting—and preserves the configuration that already worked.

Keep security options tied to a clear purpose

Before changing advanced options related to certificates, HTTPS, or request handling, understand their purpose and scope. A routine server import or first connection doesn’t require a series of extra certificate steps. If you need a specialized feature, save a separate configuration and verify it according to its instructions; don’t mix test conditions into your everyday setup. If a change lowers the requirements for verifying a remote identity, check the original settings first rather than using it as a general troubleshooting shortcut.

A simple change log can note the original value, reason for the change, test result, and whether you kept it. Being able to return to the last working state is more reliable than relying on memory. If a change doesn’t solve the problem, revert it instead of keeping it just because you tried it. Finally, check the active configuration, Global Routing, and default server, then test a real request to confirm the result.

08 / MAINTAIN

Updates, Backups, and Everyday Troubleshooting

Keep a working setup you can restore

Good maintenance isn’t about frequent changes; it’s about knowing why your current setup works. Keep a verified configuration and note the default server, Global Routing mode, and essential global settings. Save a copy before editing and use descriptive file names instead of a confusing series of numbers. Change one related set of items at a time, then verify before replacing your everyday configuration. If a problem occurs, you can trace it to the latest change and roll back.

Back up rules you edited and essential settings, but protect sensitive details separately. Don’t leave server passwords, private keys, or subscription URLs in publicly accessible documents. Before using the client’s current export, backup, or restore feature, check what data it includes and save it somewhere you control. A backup isn’t proven until it can be restored; if needed, test a copy to make sure it opens, and keep the original details.

Application updates and subscription updates are separate

Update the app through the App Store; update subscription-managed server details in the client. These are independent processes. An app update won’t renew expired credentials, and a subscription update won’t change your App Store purchase status. Before updating the app, save important configurations and read the App Store notes. Afterward, check the active file, default server, and connection status; the app opening successfully isn’t the only verification you need.

After a subscription update, check groups, entries, and the default selection. If the service provider removed a server, you may need to choose a new default. Matching names don’t guarantee that the underlying settings stayed the same, so compare them with your existing details if something goes wrong. If an update fails, keep the working entries and determine whether fetching or parsing failed before retrying. Don’t update both the app and subscription before checking which change affected the connection.

Restore a device or installation in three stages

Restore access to the app first, server details second, and configurations and settings last. For the first stage, check your App Store purchase history. For the second, use the subscription or server details you’ve kept safe. For the third, import your backup and verify its scope. Restoring in this order helps avoid ending up with an installed app but no server, or an imported server with empty rules.

On a new device, check system permissions and compatibility again; system requirements are as listed on the App Store page. Don’t assume permissions from the old device transfer completely, or that restoring a purchase restores local data. After restoring, test one server and one destination before enabling On Demand or other additional conditions. Keep the old device working until you’ve verified the transfer so you have a direct point of comparison.

Narrow down the failure by stage instead of resetting everything

When something goes wrong, describe the symptom first: can’t start a connection, test times out, some requests fail, or traffic takes the wrong route? Then check what changed recently, such as a network switch, subscription update, rule edit, or system setting. Start with the layer related to that change. A full reset removes clues and working settings at once; consider a broader restore only when you understand its impact and have a backup.

For more information, see Getting the App for purchase and restore questions, Getting Started for basic instructions, or Troubleshooting for common issues. Keep interface labels and error messages in their original wording to help identify the relevant feature. If server details are incomplete, check the information from your existing provider; changing rules repeatedly won’t fill in missing protocol fields.

Keep everyday checks concise

A maintenance note only needs to answer four questions: which configuration is active, which server is the default, what changed recently, and what were the test results? The network and steps to reproduce an issue are more useful than a collection of unsorted screenshots. Once it’s resolved, record the cause and how to roll back, and remove credentials from any shared copy. The next time a similar issue occurs, check whether the cause is the same instead of repeating every previous change.

Finish by checking the actual setup: the current mode is what you expect, the target request works, the routing decision makes sense, and temporary test options are restored. Once the connection works, there’s no need to keep adding settings. A clear, verifiable, reversible configuration is easier to maintain than a collection of files with unclear purposes. Revisit the guide’s eight stages as needed: identify the layer, check the input details, then verify the result with the same request.