Settings Layers and Defaults
Check defaults on your device; examples are not a factory settings list.
Identify which layer a setting belongs to
A single visit can be affected by three layers of settings. System networking determines whether you are on Wi-Fi or cellular and whether a VPN connection is allowed. Shadowrocket Settings control some app-level behavior, while the active Config provides rules and configuration parameters. The server selected in Home also determines the connection details in use. So seeing a value in Settings does not prove that every request uses it. Before troubleshooting, note your current network, selected server, Global Routing mode, and active config file. This helps avoid checking a setting in a file that is not in use.
Before opening Settings, identify the problem you are trying to solve. For example, a domain that will not load calls for checking resolution and routing; automatic connection after a network change calls for checking On Demand; different lists on a new device call for checking sync. Do not enable several switches just because their names sound network-related. The location and availability of options may vary with the app and system environment. This guide retains their English names as search terms; if an option is not present in your interface, do not substitute a different switch with a similar name.
How to record defaults and recommended values
This guide does not treat the value on one device as the default for everyone. A newly created config, an imported file, and restored app data may each start from a different state. When checking defaults, distinguish the app's initial settings, values explicitly set in the active config, and behavior inherited when no value is specified. Do not erase existing data just to inspect an initial state: you could lose information, and it would not restore the parameters originally included in an imported file. A safer approach is to record the current state, then use the notes for each setting to decide whether a change is needed.
Recommended values also depend on how you use the app. If your device is working reliably, keep the current settings. For temporary diagnostics, minimize variables. Configure specific DNS, automatic connections, or local Proxy access only when you need them. When recording a value, note its location, config file name, reason for changing it, and test result. An empty field does not necessarily mean disabled; it may indicate inheritance or automatic selection. Treat a blank as a specific behavior only when the interface or config semantics make that clear.
| Location | What to record | What to check |
|---|---|---|
| Home | Server, connection switch, Global Routing | What is actually in use |
| Config | Active file, rule order, General parameters | Whether the file is actually active |
| Settings | Current values of relevant options | Scope and inheritance |
| System Settings | Network type, VPN authorization status | Whether the system allows a connection |
Treat each change as a complete test cycle
Before changing a setting, choose a repeatable test, such as opening and refreshing the same webpage. Afterward, test the same target with the same network and server. If needed, disconnect and reconnect to rule out an existing connection. If the result does not improve, restore the value you recorded instead of layering on another change. Test network switches, server changes, and rule edits separately; otherwise, even if access returns, you will not know which change helped.
When the system prompts you to “Add VPN Configurations” during your first connection, treat it as the authorization step that allows the app to establish the relevant network configuration—not as a subscription import step. Denying authorization and entering incorrect server parameters are different problems. If the system entry was removed, follow the normal connection flow to handle authorization again; changing DNS or rules will not make up for it. For more on the prompt, see the VPN configuration prompt guide. For purchase record issues, use the purchase verification page.
DNS: Resolution Sources, Paths, and Caching
First confirm that the problem is DNS-related; then decide whether to change dns-server.
What DNS settings actually change
DNS translates domain names into addresses needed for a connection, but it is not the proxy connection itself. A visit can fail before DNS resolution because the server connection failed, or resolution can succeed while the connection to the destination fails. So a webpage that will not load is not necessarily a DNS problem. Start by checking the scope: do all domains fail, just one, or only domains on a particular network? Existing connections and cached results can also mask the issue, making the same setting seem inconsistent. Confirm the behavior with a new request.
In a config, dns-server specifies the DNS resolution source to use. In this example, system means to use the system-provided resolver. It is one way to establish a baseline, not the default for every imported config or a guarantee that it suits every network. The system resolver may change with the Wi-Fi or cellular network and its configuration. If your existing config explicitly sets up a dedicated DNS behavior, read its documentation first and understand how requests reach the resolver before replacing it.
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTChoosing a value and a test method
If you have no special requirements and your config is working, keep its current DNS settings. For troubleshooting, you can use the system resolver in a copy of the config as a comparison, leaving other parameters unchanged. With an encrypted DNS address, also consider how its hostname is resolved, whether the connection path is reachable, and whether certificate validation succeeds. Entering an address in a field does not guarantee that DNS requests will follow the route you expect. Likewise, reaching a resolver does not mean every address it returns is accessible through your current network path.
Do not judge a DNS resolver by its location or name alone. Check whether the current network can connect to it, whether queries receive reasonable responses, and whether the returned addresses suit the route that will be used next. Some sites return different addresses depending on the resolver, so a change in access after switching DNS does not necessarily mean either resolver is faulty. Check the returned address separately from how the client connects to it; if needed, use the Log entry for the same destination as a reference.
IPv6, Caching, and Network Changes
A domain may resolve to both IPv4 and IPv6 addresses. If a path supports only one address family, the problem may appear as slow loading on some sites, a long wait on the first visit, or recovery after switching networks. Do not start by deleting or changing all your rules. Check which address types your local network supports and whether the server and protocol can reach them, then inspect the destination address type in Log. If the interface offers address-family options, record the current value and test one change at a time. Do not treat disabling an address family as a universal long-term fix.
After a DNS change, running apps may reuse existing connections, while the system, apps, and remote services may each cache results. A single refresh right after saving the config is not enough to prove that the new setting is working. Disconnect and reconnect Shadowrocket, make a new request, and use Log to confirm it is new. Do not repeatedly clear all app data to deal with caching; that adds more variables. When comparing results, avoid switching between Wi-Fi and cellular at the same time, since both the resolver and network path would change.
If only one domain has a problem, check its spelling, matching rule, and assigned policy first. If all domains fail, check whether the resolver is reachable. If the domain resolves but the connection fails, check the server, destination port, and routing. When reporting a problem, share only the redacted domain, test time, network type, and stage where the error occurred. Do not reveal a full subscription or access credentials. For a more complete step-by-step process, see the four-step checklist for when the switch is on but sites will not load.
Global Routing and Config Parameters
Config, Proxy, and Direct are the corresponding routing modes.
Check the mode before the rules
Global Routing determines how to interpret the current routing behavior. Config applies rules from the active config; Proxy routes traffic through a proxy; Direct uses a direct connection. These modes can provide useful comparisons for troubleshooting, but their names alone do not tell you how all system traffic is handled. System bypass paths, bypass behavior in the config, and traffic outside the connection-handling scope may also matter. Before checking a rule, make sure the current mode is Config. If you edit a rule while using another mode and see no change, that does not prove the rule syntax is invalid.
App-level options in Settings and parameters in Config may each affect connection behavior. A value shown in one place is not necessarily the entire effective configuration. After importing a file, confirm which file is active, then inspect its [General] and [Rule] sections. Editing a different file in the list does not automatically replace the active config. When behavior differs from what you expect, first note the active file and the rule that matched. This is usually easier and safer than importing the whole file again.
| Mode | Primary use | What to check next |
|---|---|---|
| Config | Check rule matching and policy assignment | Confirm which file is active |
| Proxy | Compare behavior through a proxy route | Check the server and destination connection |
| Direct | Compare with a direct local connection | Restore the previous mode after troubleshooting |
General Parameters and Rule Order
bypass-system concerns bypassing system traffic, while skip-proxy lists address ranges to exclude from proxy handling. The private address ranges below are examples for understanding the syntax; do not replace an existing list without checking it. Your network may use additional ranges or have specific access requirements. DNS, bypass lists, and rules are separate decision layers. A domain assigned PROXY is not necessarily enough to make all related traffic ignore other conditions.
[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECTRules are generally evaluated in order, and an earlier match can affect whether later rules are checked. This example handles example.com and its subdomains first, then a specified address range, and finally uses FINAL as a fallback. DOMAIN matches a full domain; DOMAIN-SUFFIX matches a domain suffix; DOMAIN-KEYWORD has a broader scope and can match unintentionally. IP-CIDR and IP-CIDR6 match address ranges; do not enter domain text as an IP rule.
How to tell whether a change worked
Start with a minimal rule set for comparison instead of importing a longer list. To proxy only a specific site, use the DOMAIN-SUFFIX rule and FINAL,DIRECT shown above, then adjust the fallback behavior to suit your needs. The policy name must exist in the active config; do not enter an undefined name. After editing, save and activate the config, then make a new request and check the matching rule. If an earlier rule matched instead, fix the order rather than adding the same domain again.
Rule evaluation also depends on the information available for a request. If only the destination address is available for a connection, the expected domain-based match may not be reproducible. A webpage may also request resources from multiple domains; if the page loads but images fail, inspect each related connection. Do not use one page load to judge whether all rules are correct. Choose one domain, check its request, matching rule, and policy, then expand the test. For rules that proxy only selected sites, see the DOMAIN-SUFFIX and FINAL configuration guide.
On Demand: Triggers and System State
On Demand controls when a connection starts; it does not replace request routing in Config.
Separate “when to connect” from “how to route”
On Demand lets the system trigger connection behavior under configured conditions. It concerns when a connection starts or stays active; rules in Config determine how requests within their scope are handled. These are different functions. Enabling On Demand does not fill in server details or route every site in a particular way. If your existing server cannot connect, fix that in a manual connection first, then configure automatic triggers. Otherwise, repeated system attempts can make the issue harder to observe.
When checking the current On Demand settings, look at both whether it is enabled in the app and the status and conditions of the system VPN configuration. Existing configurations, restored data, or previous settings can affect the current state, so this guide does not prescribe On or Off as a universal factory setting. If you are making your first connection or troubleshooting, keep the manual connection flow under your control. Once it is stable and the relevant network conditions are clear, set up On Demand rules that match your needs.
Test each network condition separately
If the current interface offers conditions related to Wi-Fi, cellular, or network identifiers, first determine what each condition covers. Networks with the same name are not necessarily identical, and public Wi-Fi may require web-based sign-in first. Seeing a familiar Wi-Fi name does not guarantee that automatic connection will work. After configuring the conditions, test switching from cellular to Wi-Fi, switching back, and reconnecting after a brief network outage. Record whether the system and app statuses agree.
Start testing with a simple condition: use one clearly defined network condition and confirm that it triggers as expected before adding exceptions. When multiple conditions are present, check the interface's explanation of order, matching, and actions rather than guessing priority from list position. A condition with too broad a scope may mask later exceptions. For each new condition, test at least one scenario where it should trigger and one where it should not. This confirms its boundaries, not just that the switch can be enabled.
When the network changes, an existing connection may drop and need to be re-established. A failed old connection in an app does not necessarily mean On Demand failed; a new connection may already be active while the old session cannot continue. Make a new request, then check the VPN status. Conversely, a system status showing VPN connected does not prove that the selected server can reach the destination. Automatic triggering, tunnel establishment, and destination access are consecutive but separate stages. Record each one so that a failure in a later stage is not blamed on the trigger condition.
How to stop a connection and revert changes
With On Demand enabled, manually disconnecting may be followed by the system reconnecting as soon as its conditions are met. That does not necessarily mean the button is broken. To stop temporarily, pause the relevant automatic connection conditions first, disconnect, and check whether any other active automatic trigger remains. The exact controls depend on what the system and app show. Do not repeatedly remove and re-add all VPN entries just to disconnect temporarily; that mixes up authorization, trigger, and connection issues.
On Wi-Fi that requires network sign-in, first confirm that the local network is ready before enabling automatic connection. Otherwise, DNS, the sign-in page, and the remote connection may all be waiting at once, making it look as though the whole network is down. For troubleshooting, switch temporarily to manual connection, complete network sign-in, and test again. This helps isolate network readiness; it is not a recommendation to disable On Demand permanently. On work- or school-managed devices, follow the device management policy rather than removing system configurations at random.
You should be able to summarize the final settings in one sentence, such as “Connect automatically on verified networks; pause On Demand during diagnostics.” If you cannot explain what each condition does, reduce the number of conditions first. After each change, record the trigger result, selected server, and whether authorization was required. If the result differs from expectations, restore the last verified settings. Automatic connection reduces repetitive steps; it does not guarantee connection quality. You still need to verify server availability, subscription status, and the active config. See Frequently Asked Questions for related issues.
Ping and Connectivity Test
Confirm what the test measures before interpreting its value or failure message.
Ping is not the same as browsing speed
Ping is often used in the interface as a general label for connection tests, but the underlying test may use different methods. Check which method is in use rather than treating every result as the same round-trip time. Probing a server address, connecting to a port, and visiting a specified URL through a proxy each test a different stage. A server responding to a probe does not prove that protocol authentication will succeed; a port connection does not confirm that app-level parameters, certificates, or destination access are all correct.
A low reading does not directly imply high download speeds. A short test mainly observes connection setup and response time; sustained transfers are also affected by your local network, server load, network path, and destination site. One failed test does not mean a server is completely unavailable; the current path may simply not support that test method. When reviewing results, keep at least four details: test method, target, network type, and test time. Without this context, comparing two numbers in a list can mistake different measurements for the same quality metric.
| Test target | What it can tell you | What it cannot tell you on its own |
|---|---|---|
| Address probe | Whether the probe received a response | Whether proxy protocol authentication is correct |
| TCP connection | Whether a connection can be made to the specified address and port | Whether the destination webpage will load |
| URL request | Whether the specified request completed | How all sites perform during sustained transfers |
Choosing a test method and URL
Use the values shown on your device for the relevant test options in Settings; do not treat screenshots shared by others as universal defaults. If the existing test results are stable and reflect your actual use, keep them. For diagnostics, choose a method that matches the stage you are investigating: check the connection layer for a server port, and use the corresponding URL test for access through a proxy. Available methods depend on the current interface. Do not keep switching methods to chase a lower displayed number; doing so makes past results hard to compare.
If the test accepts a URL, choose a stable target that you have confirmed is accessible and that returns the response the test expects. Redirects, login pages, certificate errors, and rate limits can cause a test to fail even when ordinary browsing behaves differently. The example.com in this guide illustrates the format; it is not a promise of a long-term testing service. Do not enter a URL with private access parameters in a test field that may appear in Log, or you could expose it when sharing diagnostic information.
Keep comparable test records
Choose one server and one test target, then run a small number of tests on the same network. Check whether failures persist and whether results vary widely. Do not draw conclusions from one outlier or run frequent tests across every server. If the test provides a timeout threshold, treat it as the maximum wait, not a network quality target. A shorter threshold marks slower responses as failures sooner; it does not make the connection faster. A longer wait cannot fix an incorrect address, port, or protocol credential.
If list tests succeed but a webpage fails, check whether its requests use the same server, whether Config assigns them a different policy, and whether another resource domain is failing. If tests fail but browsing works, check the test target and method instead of immediately replacing all settings. Interpret Connectivity Test results in light of what they test. Test tools provide evidence for locating a failure; they do not replace real-world access checks or prove that every app will work.
For a final local network comparison, switch only between Wi-Fi and cellular. Do not also change the server, protocol, or DNS. If results change with the local network, check network restrictions and address reachability. If results are consistent, continue checking server parameters and the remote path. When testing is complete, restore the Global Routing mode you need and stop unnecessary batch probes. For a layered approach to persistent speed issues, see the guide to checking network, protocol, and route issues. Do not treat latency as a measure of bandwidth.
Log and Data: Error Stages and Statistics
Use Log to trace an individual request and Data to view statistics over a period of time.
How to capture a useful Log
A useful Log is not necessarily a longer one; it is one that can be tied to a specific action. Before troubleshooting, note the current network, server, Global Routing mode, and active config. Then enable the necessary logging in the current interface, make one request that fails, and inspect the entries around that time. If the interface offers different logging scopes, choose one broad enough to capture the issue. A long-running mix of logs contains many unrelated connections, making it harder to identify which error belongs to your test.
Check the initial state of logging switches and recording scope on your device. For everyday use, keep the settings you actually need; temporarily expand logging while reproducing a problem, then restore the original values. Keeping detailed logging enabled does not improve connection quality; it only provides more information. Before clearing old entries, decide whether you still need them as diagnostic evidence. A safer approach is to save relevant redacted excerpts first, then run a new test with a clearly defined time window instead of clearing and repeating actions at random.
Read Log by request stage, not just by searching for error terms
When reading Log, look for clues in this order: destination identification, rule match, address resolution, remote connection, protocol exchange, and data transfer. The actual log may not show every stage or present them in this exact order, so draw conclusions only from the available evidence. When you see a timeout, first identify what timed out: the resolver, proxy server, or destination site. Each points to a different fix. Do not respond to the same error term by always changing DNS or replacing every server detail.
If a request matched DIRECT, start by checking the rule and local direct route. If it matched the expected proxy policy, check the server connection and protocol parameters. For authentication failures, verify the password, identifier, or other parameters in your existing details. For certificate errors, check the destination name, time, and certificate requirements; disabling verification is not a general fix. If the expected request is missing, check the Log scope, whether a new connection was made, and whether the request falls within the current handling scope. Do not conclude from this alone that the app is not running.
How to interpret Data readings
Data is better for tracking cumulative changes than proving whether a single connection succeeded. Before reading upload, download, or total values, check what the current view counts and when its statistics began. If the interface offers views by server or app, note what each grouping represents. A server with a historical reading was not necessarily used just now. An app with no new data may reflect connection reuse, a delayed statistics refresh, or handling scope. Check Log alongside a real test before drawing conclusions.
Data and system traffic statistics can differ because their time ranges, traffic attribution, connection overhead, and coverage may not match. Before comparing them, use the same observation window and record the change in values instead of comparing totals with different start times. If a reset option is available, it only changes the relevant statistics; it does not fix a connection. Do not reset before saving a baseline, or you will lose a useful reference. To compare server and app views, see the guide to traffic readings on the Data page.
Redact diagnostic materials before sharing
Logs and configs may contain subscription URLs, server details, authentication parameters, and destination sites. Check everything before sharing, not just one password: query strings in full URLs, QR code contents, request headers, config comments, and the edges of screenshots may all expose sensitive information. In most cases, you only need to share the time of the problem, a redacted error excerpt, the current mode, and reproduction steps. Keep enough context to identify the stage; there is no need to publish a complete config to prove that a problem exists. After diagnostics, handle temporary exported files according to your usual data security practices.
Widget and iCloud Sync
Displaying status, saving data, and establishing a network connection are three separate things.
How to check Widget status
Widget provides a convenient way to view or control certain items; available styles and behavior depend on the components offered by the current system and app. The system may limit background refresh, so the status shown in a Widget may lag behind a recent change. If it appears out of date, open Shadowrocket and check the actual connection and selected server in Home, then confirm with a new request. Do not rely on Widget text alone to confirm a connection, and do not change protocols, rules, or DNS just because the Widget refreshes slowly.
After adding or changing a Widget, check that it is linked to the intended content. Then test changing status in the app, using the system Widget control, and checking the display after unlocking the device. If an action requires opening the app or a system confirmation, follow the current prompts. System authorization, On Demand conditions, and server availability still apply; a Widget cannot bypass them. Keep only Widgets whose purpose you understand, so different status refresh times do not lead to confusion.
iCloud Sync Does Not Sync Connections
iCloud sync saves and transfers data that is eligible to sync. It does not make two devices connect at the same time or give them identical system authorization, network conditions, or temporary state. Check the options currently provided by Shadowrocket for the actual sync scope; seeing an item in a list does not mean every setting was copied. Check the server list, config files, selected items, and app-level settings separately. In particular, confirm which Config is active on the destination device.
Check the default state of sync switches on your own device. If you want to manage existing data across devices, first confirm that the expected personal account is signed in and iCloud is available, then check Shadowrocket's sync options. If you do not need cross-device access, you can keep the current setup. Before enabling sync, keep a local copy: sync is not a backup with a guaranteed version history. Accidental deletion, overwrites, or conflict resolution may propagate to another device, so do not treat a second device as a permanently independent recovery source.
Handling sync delays and conflicts
If lists differ between devices, first check the account and sync scope, then confirm both devices have a working network and allow time for the system to sync. Do not edit the same config on both devices at once or repeatedly switch sync off and on to force a refresh; this makes the cause harder to identify. Choose one device as the source for this edit, record its contents, then check the other device for the change. If the current interface offers an explicit import, export, or restore option, find out whether it merges or replaces data before proceeding.
Config names alone are not enough to resolve a conflict; files with the same name may contain different rules. Compare key parameters, rule order, and your own notes about changes. Keeping two copies for comparison is safer and easier to undo than overwriting one directly. After syncing, check the selected server, Global Routing mode, VPN authorization, and On Demand on the destination device, then test access there. A working source device only confirms that its own setup works; it does not replace a test on the destination.
Your existing subscription and local config are also separate. Syncing a subscription entry does not mean its contents have just been fetched again; remote subscription updates and iCloud data sync are different processes. If the entry is present but its contents are old, check the result of updating that subscription rather than just waiting for system sync. Treat subscription URLs as sensitive access credentials; do not post a full URL publicly just to compare content between devices. This section covers management of your existing data only; it does not provide or recommend services.
Check purchase and data separately when changing devices
App Store purchase eligibility, app data restoration, and network connection authorization are separate matters. Being able to redownload a purchased app does not guarantee that all local configs will be restored. Restored configs do not mean the new device has completed its first VPN authorization. When changing devices, check in this order: get the app, check your data, select a config, complete authorization, and test access. For purchases and redownloading, see the guide to restoring a previous purchase. If your old device still works, keep its data until you have confirmed the new device is working, so you do not lose your only recoverable copy during migration.
Proxy Ports, Access Scope, and Reverting Settings
Local listening ports and remote server ports serve different purposes. Identify which one you mean before changing it.
Do not confuse the two types of port
The port in Add Server is part of your existing server connection details and must match the protocol and port the remote server actually listens on. If Settings offers a local Proxy port, it is the listening port for a proxy service on your device, for use by compatible client requests. Changing the local port does not change the remote server config or fix an incorrect remote port. When checking, clarify who is connecting to whom: is Shadowrocket connecting to a server, or is a requester on the same device connecting to the local Proxy entry point?
The names, supported protocols, and access scope of local Proxy options depend on the current interface. This guide does not give a universal default port because device state, existing settings, and feature status can vary. If you do not need a local Proxy entry point, keep the current settings; there is no need to enable an extra listener for an ordinary VPN connection. If you do need one, record its listening address, port, protocol, and whether other devices can access it. Confirm that the connecting client uses a compatible protocol.
The listening address determines who can connect
Local-only access and access from the local network are different scopes. A loopback address is generally accessible only from the same device; listening on a network interface may allow other devices on the network to attempt a connection. Matching port numbers do not guarantee that two endpoints can communicate. Also check that devices are on the same reachable network, that client isolation is not enabled, whether the address has changed, and whether the system and app allow the connection. Use the current feature documentation and test results to determine the actual access scope.
Before expanding access, confirm that it is necessary and use the access controls provided by the feature. Do not make a broader listening scope your first fix for a failed local connection. On unfamiliar networks, keep access as restricted as possible so unrelated devices cannot use the Proxy entry point. When you are done, disable any listener or access option you no longer need and confirm that requesters no longer point to the old settings. Otherwise, a requester still using an outdated address may keep failing after the app's state changes, making the problem look like a network-wide outage.
| Symptom | Check first | Do not confuse with |
|---|---|---|
| Remote connection fails | Address, protocol, and port in Add Server | A local listening value cannot replace remote server details |
| Local entry point cannot be reached | Whether listening is enabled and the protocol and port match | A connected VPN status does not guarantee that a listener is active |
| Other devices cannot connect | Access scope, network isolation, and address changes | Do not change remote server credentials first |
Distinguishing conflicts from unreachable ports
Multiple services generally cannot use the same port on the same listening address at the same time. If the interface or Log reports a bind failure, first check for a conflict and confirm that the port value meets the input requirements. Do not keep changing the remote protocol. If the service is listening but the requester cannot connect, check the address, network path, and protocol choice. HTTP and SOCKS5 use different connection methods. If the requester selects the wrong protocol, a connection may be established while the request still fails; a reachable port alone does not prove that the setup is correct.
When troubleshooting a local entry point, test within the smallest access scope first and expand it only if needed. Keep the remote server and Global Routing unchanged, change one local parameter at a time, and update the corresponding value on the requester. If you change the port but do not update the requester, the test fails because the two sides no longer match; that does not mean the new port is unusable. Record the listening scope, both port values, connection protocol, and error stage. You can redact network addresses, but keep enough context to tell the local and remote roles apart.
Return all changes to a recoverable state
After troubleshooting, work through your notes and revert settings one by one: restore any test mode you no longer need, turn off temporary expanded logging and listeners, confirm that On Demand conditions are still appropriate, check the active Config, and test a known destination. Do not use “reset all settings” as a substitute for individual reversions unless you know what data it affects and have kept a complete copy. A good diagnostic session leaves fewer unknowns, not more switches whose purpose is unclear.
If you still cannot identify the issue, note the current network, selected server, mode, config name, reproduction steps, and redacted Log entries. Then review the server, DNS, rules, and system authorization in turn. For a newly appearing issue, start with the most recent change. If nothing changed but the problem appeared suddenly, check the local network and existing service status. To follow the full setup process again, return to the setup guide. To search by symptom, visit Frequently Asked Questions. Keeping the smallest reproducible setup is more useful than adding more untested parameters.