Settings scope and default values
Identify which layer a setting belongs to before deciding what to change. Settings is the app’s settings screen, but a connection is also affected by the server selected in Home, the Global Routing mode, rules in Config, and the system’s network conditions. An enabled switch alone does not prove that requests are being handled as expected. When troubleshooting, note the current server, Config, and connection status together so you don’t mistake issues from different layers for one setting’s problem.
App settings, Config files, and server details
App settings generally control behavior such as testing, display, logging, and system integration. Config stores rules and related network settings, while server entries contain protocol, address, port, and authentication details. A “port” can mean very different things depending on where it appears: Port in Add Server refers to the remote service, while a local Proxy listening port is an entry point on your device. Check which screen you’re on before changing anything; similar wording in an explanation does not make the values interchangeable.
Importing an existing subscription primarily adds server entries and their update source; it does not necessarily replace the active rules file. Updating the app, reimporting a Config, and switching servers are also separate actions. If a value changes after an update, first identify what was updated, then check whether imported content overwrote it. Repeatedly importing without checking can mix existing and new entries, making problems harder to trace.
| Location or item | What it affects | How to verify |
|---|---|---|
| Settings | App behavior, tests, and system integration | How the relevant feature behaves |
| Config | Network settings in rules and Config files | The active file and request records |
| Add Server | Remote server connection details | Original server details and connection results |
| Global Routing | Select a Config, proxy, or direct connection mode | How the request is actually handled |
There is no single default value for every device
This guide does not treat a value shown on one device as a permanent factory default. The state after a fresh install, a device migration, or a Config import may differ; some options may also change with system capabilities and app behavior. Before changing anything, check the current field, its help text, and the active Config, and keep a record you can restore. If you don’t have a specific reason to change a value, leave it as is rather than matching a list item by item.
At minimum, record the option name, its original and new values, and why you changed it. An empty field does not automatically mean disabled or invalid: it may use information provided by the system or defer to the Config. Check the field’s description to understand its meaning. If you’re unsure, leave it unchanged and test in a controlled way. Don’t fill every blank with a guessed public address or number.
Make changes and rollbacks repeatable
Start with a baseline test on a stable network: confirm that a connection can be established, open a familiar page, and note Global Routing and the active Config. Then change one variable and retest the same page on the same network. If you change DNS, the server, and rules all at once, you won’t know which change helped—or which one caused a problem. Changing one item at a time is more useful for troubleshooting than repeatedly resetting everything.
If the interface says a change to a core connection setting requires reconnecting, follow its instructions. If it doesn’t, save the change, then disconnect and reconnect to avoid using an old session. A connection that continues working is not proof that the new value has been tested. To roll back, restore the original field and Config, then repeat the same test. If the problem remains, check for changes to the network, server status, or system settings.
DNS and domain name resolution
DNS resolves domain names to addresses used for subsequent connections. It can affect rule matching, but it does not replace rules or fix server authentication failures. First identify what is going wrong: a domain lookup error, a connection timeout after an address was returned, or a connection that succeeds but loads incomplete content. Only the first points directly to DNS. The others require checking routing, transport, and the server’s response; they should not all be treated as DNS issues.
Check where DNS settings come from
First check whether the active Config contains DNS-related settings, then review the DNS options and descriptions available in Settings. If related fields appear in both the interface and the file, don’t assume one necessarily overrides the other based on location alone. Confirm whether an option controls global behavior, supplements the Config, or belongs to a particular resolution mode. Fields with DNS in their names may handle different stages rather than duplicate each other. Verify the change with a new request, not just by checking that it saved.
If your current Config works, it’s usually best to keep its existing DNS behavior. Change a related field only when you can reproduce a resolution problem, need to use your own DNS service, or have a Config that explicitly requires it. Before entering an address, check whether the field accepts a single address, a list, or a URL with a protocol. Don’t paste a full webpage URL as a DNS server address; follow the field’s requirements for protocol, port, and path.
The DNS service itself also needs to be reachable. With encrypted DNS, the service name may still need to be resolved first, and certificate checks depend on the correct name and system time. Switching to encrypted DNS does not make other network requirements irrelevant. If you encounter a dependency loop or connection failure, restore the previous DNS settings first, confirm the basic network works, then check whether the new service is reachable and configured correctly. Don’t keep adding more DNS addresses without diagnosing the issue.
Domain rules vs. IP address rules
DOMAIN and DOMAIN-SUFFIX can match a request based on its domain. IP-CIDR, IP-CIDR6, and GEOIP match address-related conditions. Where a rule needs an address, DNS results may affect what happens next; whether the request retains its domain and whether an earlier rule already matched also matter. When troubleshooting rules, read them from top to bottom and identify the matching rule before considering DNS. Don’t focus only on the IP rules at the end of the list.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet illustrates rule order only; it is not a complete connection Config and does not need to replace your existing file. example.com is a sample domain, the private address rule demonstrates address-range matching, and FINAL handles requests that did not match earlier rules. Before adding anything to your Config, check existing rules, policy names, and the intended request path. A snippet that saves successfully is not necessarily right for every network; consider its effect on local network resources and existing rules.
Caching, network changes, and a recommended test sequence
After a DNS change, your browser, app, or existing connection may still be using an earlier result. Close the page or app session you’re testing, reconnect if needed, and send a new request to the same domain. Don’t expect a domain to always resolve to one fixed address: a service may return different addresses depending on the network and load. Focus on whether resolution succeeds, the request follows the expected rules, and the connection behaves consistently—not whether the address matches someone else’s.
If a problem occurs only on one Wi-Fi network, first confirm that any required web login has been completed, then check for conflicts between local network resolution and the current DNS settings. If it happens briefly only after switching networks, distinguish a stale cache from a tunnel that has not reconnected yet. If restoring the original settings resolves the issue, check the new fields one by one. If the original settings also fail, look at the underlying network and current server instead of repeatedly changing DNS addresses.
On Demand connections
On Demand controls when the system starts or maintains a connection based on matching conditions. It is not a list of domain rules for choosing a proxy or Direct. The first answers “when should a connection start?”; the second answers “how should requests be handled once connected?” Confusing the two can lead you to expect a domain rule to start the connection automatically, or assume that a network condition means all requests must use a particular server.
Verify manual connections before adding automatic conditions
When setting things up for the first time, keep the current On Demand state and use Home to connect manually. Confirm that your existing server details, Config, and Global Routing work. A stable manual connection gives you a reliable baseline for testing automatic triggers. If manual connection fails, fix that first; On Demand starts the same connection process and cannot supply missing authentication details or make an unreachable server accessible.
On the On Demand screen, review each available condition, such as network type, network name, or other matching criteria, and confirm the rules after saving. Don’t assume your device has exactly the same options as someone else’s screenshot. Enter network names as they appear on your device; similar names do not refer to the same network. If there are multiple conditions, read how the interface handles matches and exceptions before combining them, so the rule does not cover more than you intend.
If you don’t need automatic connections, keep manual control. If you do, start with one condition you can test repeatedly. For example, test one commonly used network state and observe what happens both when the condition becomes active and when it stops matching. Add other conditions only after confirming the first. Avoid covering every network at once: an issue could affect all your connections and be hard to distinguish from a problem establishing the connection itself.
System permissions and network changes
The first time you connect, the system may ask permission to add a VPN configuration. This lets the system create the network configuration; it does not verify your subscription or server details. You still need to test the connection. If you previously denied permission, follow the current system prompt to allow it. Repeatedly toggling On Demand is not a reliable way to request permission again, and deleting other system configurations at random is not recommended.
When switching from Wi-Fi to cellular, the old connection may drop and a new one must be established under the new network conditions. A brief wait does not mean the On Demand rule has failed. First confirm that the system has switched networks, then check Shadowrocket’s connection status and send a new request. If the network still requires authentication, the signal is unstable, or the current server is unreachable on the new network, an automatic trigger cannot guarantee an immediate response.
System behavior in the background is not identical to foreground app behavior. The interface not updating in real time after you leave the app does not prove the tunnel has stopped; a status icon still showing does not prove every request is succeeding. Check the connection status and a real access result together. If another system network configuration is involved, clarify what each one does before changing multiple automatic connection conditions at once.
Stopping connections, rolling back, and troubleshooting
If a connection comes back after you manually disconnect, an enabled On Demand condition may have triggered it again; the disconnect button may have worked. To keep the connection stopped, check whether On Demand is still requesting a connection, disable the relevant trigger using the current interface, and then disconnect. Wait for the status to settle and verify it with a normal request. Avoid rapidly tapping the switch back and forth, as the connect and disconnect actions can overlap and make the final state unclear.
Troubleshoot in a consistent order: temporarily disable On Demand and verify a manual connection, then restore one condition and see whether it triggers. Once it does, check the request path. If it never triggers, review the condition and system permission. If it triggers but access fails, check the server, DNS, and rules. If it reconnects repeatedly, note the network type and what changed when it happened instead of broadening the matching conditions first.
Ping and Connectivity Test
A test result describes a particular method at a particular time; it does not prove that every service is available. Ping-related options in Settings adjust test behavior, while Connectivity Test in Home runs the relevant check. Before interpreting a result, confirm the method, target, and whether the test uses the selected server. Different methods cover different parts of the network path, so comparing them as if they measured the same thing may be misleading.
What each test can tell you
If the interface offers a TCP test, it mainly checks whether a connection can be established to a specified address and port. A reachable port does not prove that protocol authentication, encryption negotiation, or access to the destination will succeed. An HTTP test also depends on the target and whether the request uses a proxy path. A response usually covers more steps, but still applies only to that target and request. Similar test names do not remove the need to check the path and conditions.
On a timeout, first determine whether it occurred while testing the target or connecting to the server. The remote server may be reachable while the test target is temporarily unresponsive; the target may work while the current network cannot reach the server. A single failed test does not mean the server is permanently unavailable. Repeat the test using the same method, check the underlying network and target, and compare it with a real request to distinguish an intermittent issue from a persistent failure.
| Observation | Can indicate | Does not prove by itself |
|---|---|---|
| Port connection succeeds | The transport connection was established for that test | Protocol authentication and webpage access both succeeded |
| Test target responds | The test path received a response | All targets and protocols are available |
| Test times out | The test did not complete within the allotted time | The failure must be on the server side |
Choosing a target, timeout, and retry count
Keep a test target you can verify, or choose one you can access reliably and whose purpose is clear. Don’t keep changing targets just to get a lower number; doing so makes comparisons meaningless. If the target is a domain, DNS resolution may be part of the test. Redirects or authentication requirements can also make its behavior different from a simple response, so check that the target suits the test method.
There is no single best timeout for every network. Set it too low and a high-latency connection that still works may be marked as failed; set it too high and it takes longer to detect an unusable path. For initial troubleshooting, keep the current value and observe results on a stable network before adjusting it. If requests often come close to the limit, investigate the network and server instead of masking a persistent problem by extending the timeout.
Keep test intervals and conditions consistent. Don’t rank servers while the device is transferring large amounts of data or switching networks. Testing many entries in quick succession can also add load and skew the results. A more useful approach is to test a small number of existing entries repeatedly on the same network, then consider whether real-world use is stable. One low reading is not enough reason to make an entry your long-term choice.
Test passes, but access still fails
First check Global Routing for the actual request. Testing a server does not mean your current request is using it; in Config mode, the request may match DIRECT or another policy. Next, review the rules in Config that apply to the destination, then check DNS and request records. Switching servers without confirming which rule matched may leave you comparing an entry that the request never used.
Protocol settings can also explain why a basic test succeeds while an app request fails. For example, a TLS connection needs the correct service name and certificate validation; a TCP test alone cannot confirm that UDP traffic will work. Check existing server details against their source instead of disabling validation just to pass a test. For details on Trojan fields, see How to set Password, SNI, and Allow Insecure.
When restoring test settings, restore the target, method, and timeout to their recorded values, then test the same entry again. If the result still changes, network conditions or remote responses may also have changed; the difference cannot be attributed entirely to the setting. Keep a short record of the network type, test method, result, and actual request outcome. This is more useful for troubleshooting than a number in a screenshot with no context.
Log and Data diagnostics
Log helps you inspect events and errors; Data shows traffic statistics. They complement each other but are not interchangeable. An increase in traffic only shows that data passed through the relevant counter; it does not guarantee a page loaded completely. Likewise, a log entry showing a connection does not prove that the subsequent request succeeded. Start with a specific question, such as “Did this domain match a Direct rule?”, and collect the relevant records instead of leaving detailed logging on indefinitely.
What to log and when to enable it
Check the Log options in Settings and distinguish whether logging is enabled, how detailed it is, and what you can view. Available options vary by interface; don’t treat the log level on one device as a universal default. For everyday use, keep the current settings if they’re sufficient for basic troubleshooting. For a reproducible problem, temporarily enable the records you need. Restore the original settings when you’re done to limit unnecessary records and avoid retaining sensitive local information.
Before reproducing an issue, note the current time and the destination you plan to access, then perform one clearly defined action, such as opening a page and waiting for the result. If the log is large, clear old records using the available interface before testing; if you need evidence, make a redacted copy first. Don’t test many servers at the same time as reproducing a single-page issue: test and real traffic will be mixed, making it difficult to identify the relevant error.
Read errors in sequence instead of searching only for the last failure message. A DNS error may prevent a connection from starting; authentication can fail after transport is established; a remote close may be a consequence of an earlier error. If the log shows only a brief category, use surrounding events for context rather than assigning similar errors to the same setting. Repeat the test in the same order after each change.
Use Data to check the request path
Upload and download figures in Data can help you observe activity over time, but interpret them in light of the current view, measurement scope, and reset state. Different views may group traffic differently, so subtracting two figures does not necessarily give an exact result. Note the baseline, send only the request you want to test, and check whether the relevant figures change. This is easier to interpret than a total that has accumulated over a long period.
Other apps on your device may sync, receive messages, or make background requests, so a rise in total traffic may not come from the page you just opened. To check whether a particular server was used, look for statistics or request records associated with it and compare them with the matching rule. An increase in the total alone proves neither that the destination used a proxy nor that a rule worked as expected.
A failed page can still produce a small increase in traffic. Connection setup, authentication, error responses, and retries can all transfer data; whether the full content arrived is a separate question. Conversely, a page shown from local cache may appear to load without a new network request. To test a rule, make sure you sent a new request. If needed, use a page path you can control instead of repeatedly refreshing cached content.
Redaction, sharing, and closing the troubleshooting loop
Logs and Config files may contain subscription URLs, authentication details, server addresses, visited domains, and query contents. Before sharing, remove complete credentials and unnecessary personal information. Pay particular attention to query strings, which may contain authentication data. Hiding only a password field is not enough; don’t publish an entire Config file. If you need to show the structure, replace business domains with example.com while retaining the relevant error category and rule type.
A useful troubleshooting report includes the expected behavior, what actually happened, network type, Global Routing, active Config, and one change you already tested. You can attach relevant redacted records, but there’s no need to include everything. For app availability or system compatibility, check the App Store page. To confirm a remote account is active, use the information for your existing service rather than guessing from logs whether you have access.
Widget and system shortcuts
A Widget provides a system-level way to view status or access common actions. Its form depends on the components available in the app and what the system supports. It is not a separate proxy Config and does not replace the server or Global Routing in Home. Before adding a Widget, verify the connection in the app. This makes it easier to tell whether a problem is with the Widget display or the connection itself, without changing the same state from multiple places.
Widget settings and adding a system Widget are separate steps
If Settings includes Widget options, first check whether they affect content, display, or shortcuts. Configuring something in the app does not add a Widget automatically; use the system’s available process to add it in a supported location. Conversely, a Widget already on the system does not mean every action has been initialized. Before using it for the first time, open the app and confirm the active Config and system permissions are in place.
Don’t assume that Widget names and system entry points are fixed across system interfaces. The system may offer different sizes or locations, with varying information and interaction options. Choose from what is available on your device and start with a simple layout that meets your needs. If an option does not appear, don’t change network settings to find it; first check system compatibility and the features available in the app.
Keep the default display at first, then remove information you don’t need. If other people can see the Widget, consider whether server names, status text, or statistics could reveal your usage habits. Custom names can help identify entries, but don’t put passwords, subscription URLs, or authentication details in them. Display fields are for convenience, not for storing sensitive connection details.
Checking status updates and action results
A system Widget may not update in sync with the app’s foreground screen. During a network change, connection setup, or system scheduling, it may temporarily show an earlier status. If the display looks wrong, open Shadowrocket and check the actual connection status in Home, then send a test request. Don’t rely on Widget text alone to confirm a connection, or repeatedly run opposite actions because the display has not refreshed yet.
After you start an action from a Widget, the system may need to open the app or show a confirmation screen. Follow the current prompt rather than treating an intermediate screen as a failure. Check the actual connection result to confirm the action completed. If On Demand is still requesting a connection, the system may reconnect after the Widget disconnects. Review the On Demand conditions instead of repeatedly removing and adding the Widget; that won’t change the trigger.
If a Widget does not show the expected content, confirm that you added the right Widget and size, then review the Widget settings in the app. Open the app, allow initialization to finish, and reload the Widget using the system’s controls. Only investigate DNS, the server, and rules if the connection itself is failing in the app. Separating display issues from network issues helps avoid changing connection settings that were already working.
Background activity, battery use, and system permissions
A Widget being present, the app being in the background, and a system network connection being active are three different states. Leaving the foreground does not prove the connection stopped, and you don’t need to rebuild the connection repeatedly to refresh a Widget. The system schedules background updates; app network records show actual requests. To find out what happened during a period, check Log and Data rather than relying only on whether the app is still visible.
Battery use cannot be explained by one switch alone. Frequent reconnects, high request volume, a weak network signal, and detailed logging can all increase activity. For comparisons, keep the network and usage consistent, and change one condition at a time. Don’t draw conclusions about Widget or Ping settings while the network is switching repeatedly or background sync is busy. If a change causes a problem, restore it and retest before deciding whether there is a consistent link.
iCloud sync and Config
Sync, backup, import, and subscription updates are separate processes. Sync transfers supported content between devices; a backup keeps a recoverable copy; import adds external content to the current app; a subscription update refreshes entries from an existing source. These options may be near each other in the interface, but they do not necessarily affect the same data. Before moving to a new device, list the servers, Config files, and local settings you need to keep, then choose the right method for each.
Check the sync scope and system requirements first
Before using iCloud features, check that each device is signed in to the intended Apple Account, the system allows the app to use the relevant cloud features, and the network can complete a sync. Then read the description of sync scope in Shadowrocket’s current interface. Don’t assume that all Settings values, connection states, system VPN permissions, and historical logs will sync. Check anything not explicitly listed on the new device.
An enabled sync switch does not mean the latest content has already reached iCloud. After a change, give the system time to sync, then check on another device that the relevant entry appears and matches. If the system reports a storage or network issue, resolve that first instead of importing the same file repeatedly. Repeated imports alongside sync can create entries with the same name, making it harder to tell which one is current and ready to use.
Before making large-scale edits, keep a clearly named backup and note its purpose and the Config state when it was saved. Sync is not a substitute for historical backups: accidental changes or deletions may sync too. If a backup contains credentials, store it somewhere you control and don’t share it through a public link. Don’t include a complete subscription URL in the filename. When testing a restore, start with a few entries and confirm their structure and contents before continuing.
Selecting and checking an imported Config
After importing a Config, check that the file is complete, its rules are readable, and its policy references match your current setup. Then confirm that it is actually selected as the active file. Seeing a file in the list does not mean it is enabled. If you’re trying to restore behavior from an old device, also check that Global Routing is in Config mode; otherwise, requests may bypass the rules even when the same file is selected.
Read a Config from its overall structure down to the details. Start with rule order and final handling, then review domains, address ranges, and related network settings. Don’t append a line copied from elsewhere to the end of the file: if it comes after FINAL, it may have no effect. Copy the original file before editing so you can roll back. After saving, confirm that the edited copy is active; similarly named files can make it seem as if a change did not work when you switched files instead.
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYThis example puts more specific rules first: example.com matches DOMAIN, related subdomains are handled by DOMAIN-SUFFIX, and other requests go to FINAL. It is only a rule snippet, not a complete set of server details. Before using it, confirm what each rule is for and check the existing policies and domain scope. If the Config comes from an existing source, read its changes before applying it; the filename alone does not tell you what it does.
Resolving conflicts across devices and restoring data
If two devices are editing the same content, decide which copy to keep before waiting for sync to settle. Don’t repeatedly delete and recreate entries while both devices are still making changes; that makes the final result harder to identify. Pause edits on the other device, confirm the content on one, then check it on the second. During recovery, compare the address and protocol details of servers with the same name rather than assuming they are identical.
When moving to a new device, follow this order: get the app, restore data, check the active Config, complete system permissions, and test the connection. App purchase eligibility and Config data are separate: handle the former through App Store purchases and compatibility, and restore the latter from the actual backup or sync scope. After restoring, check local Settings and On Demand instead of assuming every behavior from the old device was copied. For purchase restoration, see how to restore a previous purchase.
If entries change after a subscription update, first check the update source and which entries it manages, then see whether custom edits were retained. Don’t mistake a remote entry refresh for an iCloud conflict, and don’t change authentication details just to preserve a local name. If you need to reorganize entries, make a backup and identify which content is managed by your existing subscription and which content you maintain yourself. Keeping those roles clear makes later changes easier to track.
Proxy ports and verification
First distinguish local and remote Proxy ports. Port in a server entry is the destination port for the remote service and must match your existing server details. A local HTTP or SOCKS5 service port in Settings, if available, is a listening port for a proxy service provided by your device. They do not need to match and cannot be substituted for each other. If you don’t need a local proxy service, leave its settings as they are rather than enabling an extra listener to “improve speed.”
Listening address, port, and access scope
A port must be considered together with its listening address. An entry accessible only from the device has a different exposure scope from one that other devices on the local network can reach. Before changing it, read the interface’s notes on binding and access permissions, and confirm that other devices really need to connect. Knowing the port number alone does not mean another device can reach it; network isolation, address changes, system restrictions, and whether the service is running all matter.
If you need to enter a local port manually, choose a value accepted by the interface and not already in use, and record the original. Don’t copy the remote server’s Port into this field or use random port changes to fix every connection problem. After saving, confirm that the service starts, then connect from the intended device using the right protocol. HTTP and SOCKS5 are different protocols; swapping their port numbers does not make a client compatible.
Test a local service with the smallest access scope first, then consider expanding it only if necessary. If the device’s network address changes, other devices may still be using its old address. Don’t mistake this for a server failure, and don’t expose the service to an untrusted network without understanding access controls. When you’re done, turn off the relevant service and check whether other devices are still attempting to connect.
Global Routing determines how subsequent requests are handled
A local proxy entry accepting a connection does not mean subsequent requests will use the selected remote server. Check Global Routing and the active Config as well. Config, Proxy, and Direct are three different modes: rule-based configuration, proxy routing, and direct connections. For everyday rule-based routing, use Config after confirming the rules are correct. Proxy and Direct are better suited to situations where you understand the scope, such as testing a single route or temporarily using one path.
| Interface label | Meaning | What to check |
|---|---|---|
| Config | Config mode: handle requests according to the active Config | Active file, rule order, and policy references |
| Proxy | Proxy mode: route requests through a proxy | Selected server and actual connection results |
| Direct | Direct mode: connect without routing through the selected proxy server | Whether the current network can reach the destination directly |
When troubleshooting a domain, record its original routing mode, then temporarily compare Direct and Proxy before checking the rules in Config. This comparison only helps narrow down the cause: if Direct works and Proxy fails, check DNS, authentication, and the destination response along the proxy path. If both fail, also consider the destination itself and the underlying network. Restore the original mode after testing so you don’t mistake a temporary diagnostic setting for your everyday routing setup.
Troubleshoot by stage instead of changing everything at once
First check whether the server connection is established, then whether the domain resolves, whether a rule matches, and finally whether the destination responds. If you cannot connect to the server at all, check Address, Port, protocol, and authentication details. If the connection works but only some domains fail, check DNS and rules. If only a particular service fails, consider its transport and server requirements. WireGuard fields should not be treated like those of a password-based protocol; see Private Key, Peer, and MTU settings explained.
For MTU, UDP, or specialized transport settings, keep the values in your existing Config unless the symptoms are clear and you can make a controlled comparison. Smaller numbers and more enabled switches do not automatically make a connection more stable. Each change should test a specific hypothesis, such as whether a certain type of request fails on a particular network. If the change does not help, restore the original value instead of leaving behind a combination of settings with no clear reason.
After making changes, finish with checks that cover everyday use: confirm the current server and Config, review Global Routing, On Demand, and any temporary Log settings, then test familiar pages, any local network resources you need, and a network change. Keep useful findings and rollback notes, and remove temporary copies you no longer need. If the issue remains, use the FAQ for routing rules and connection troubleshooting with redacted symptoms and test conditions instead of repeatedly resetting settings without identifying the cause.