Shadowrocket Protocol Settings
and Connection Types
Start with your existing server details. Identify the protocol, transport, and routing, then check the settings, speed, and battery impact.
This reference manual is organized around specific questions. It explains why you might choose one protocol over another, how settings relate to each other, and which layer to check first when a connection fails. If you’re new to Shadowrocket, follow the Getting Started Guide to import a configuration and connect, then return here for details. This page isn’t a quick-start walkthrough and doesn’t provide subscriptions or server details.
The iPhone and iPad version costs $2.99 as a one-time purchase on the App Store; check the App Store listing for system requirements. The Mac (Apple silicon and Intel), Windows, Android, and Linux versions are free. See Downloads for all platforms for your options. Installers for other platforms are available from this site’s download page under /dl/.
- Check protocol and transport separately
- Measure speed and battery use separately
- Change one setting at a time
How connections are layered: a protocol isn’t the whole path
Separate three distinct questions
In Shadowrocket, the protocol determines how the client exchanges requests with the server; the transport determines how that data is carried; and routing determines which policy handles a connection. These layers are related, but they aren’t interchangeable. Choosing VLESS, for example, doesn’t also select WebSocket. Enabling TLS doesn’t mean every app’s traffic is routed through a proxy. Selecting a server doesn’t mean every rule in Config will use it. Before troubleshooting, identify each layer to avoid repeatedly changing settings in the wrong place.
A typical request passes through several stages: the local app makes a request, the name is resolved, Global Routing and the rules are evaluated, a server connection is made, authentication or a handshake takes place, and the server accesses the destination. Caching, connection reuse, or remote DNS resolution can change the order of some steps, but their roles remain the same. Seeing a server entry in Home only confirms that a configuration exists. A Connectivity Test result only confirms that the connection path used by that test works; it doesn’t prove that a particular site, UDP app, or every rule works.
Proxy protocols and tunnel protocols
Shadowsocks, VMess, VLESS, Trojan, HTTP, and SOCKS5 generally handle connections or forward requests. WireGuard tunnels IP packets, so its settings include addresses, route prefixes, and the peer’s public key. Hysteria2 carries proxy traffic over QUIC. These protocols aren’t just different names: the server must run the matching protocol, and the client’s credentials and negotiation settings must match too. You can’t enter a Trojan password in SOCKS5 and expect the connection to work just because both use the same port.
| Layer | Typical settings | What to check |
|---|---|---|
| Protocol and authentication | Type、Password、UUID、PublicKey | Does the server type match the credentials? |
| Transport and security | TCP、UDP、TLS、WebSocket | Do the channel, certificate name, and path match? |
| Routing and policy | Config、Proxy、Direct、Rule | Is the request handled by the expected policy? |
| Destination and name resolution | DNS, destination address, port | Does the name resolve, and can the destination service be reached? |
Speed needs to be assessed in context, too. The time it takes to open a page for the first time includes DNS resolution, connection setup, and the handshake. Large downloads better reflect throughput, while video calls depend more on jitter, packet loss, and the UDP path. Cutting a handshake round trip may improve the first request without increasing sustained download speed. Server congestion, available egress bandwidth, the route across networks, and destination-side throttling can all be bigger constraints. There’s no reliable, fixed ranking of protocols from fastest to slowest.
Keep variables within a range you can explain
Choose based on the details you already have: first check the protocol specified by the server, then confirm its transport, security settings, and available ports. Keep the original entry after importing a subscription and make a copy for experiments. If a Subscribe update rebuilds entries, note which values came from the subscription and which you changed locally. Don’t change the protocol, DNS, rules, and server all at once. Even if the connection comes back, you won’t know which change fixed it.
Battery use on iOS depends on the entire connection path. Protocol encryption uses processing power, retransmissions increase data transfer, keepalives wake the wireless connection, and app activity such as syncing and media decoding uses power too. The VPN status indicator only shows that the system network extension is active; it doesn’t measure power use. The test methods below separate these factors to help avoid blaming protocol overhead for an app’s background activity.
Shadowsocks: a streamlined proxy and encryption method
Design and limitations
Shadowsocks is designed to provide a relatively streamlined encrypted proxy connection. The client packages destination addresses and application data in the agreed format; the server validates and forwards requests. It isn’t a full virtual LAN solution, and selecting it as the Type doesn’t automatically set up app routing. You don’t need to memorize its history, but you do need to know that the same protocol can use different encryption methods and formats. Choose the method accepted by the server; similar names don’t imply compatibility.
Earlier stream ciphers and later AEAD methods differ in data format and authentication. AEAD combines encryption with integrity checks, allowing modified data to be detected. That doesn’t make every method with AEAD in its name interchangeable. Some newer methods also require a specific key length and format. Use the settings supplied with your server. If a method isn’t listed in the client, selecting a similar-sounding one won’t make it a valid substitute.
Address, Port, Method, and Password
In Add Server, select Shadowsocks and check Address and Port first. Address is the hostname or IP of the proxy server, not a subscription URL or the website you want to visit. Port is where that service listens. Don’t enter a full webpage path in the hostname field; enter IPv6 addresses as required by the field. If the details came from a QR code or subscription, keep the imported values and compare them with the original before editing. This helps avoid dropping a port or other parameter when splitting the details manually.
Method determines how both ends handle the key and ciphertext; Password must match exactly, character for character. Some methods derive a key from a regular password, while others require a key in a specified format, so a longer password isn’t necessarily more compatible. Watch for trailing line breaks, full-width punctuation, and invisible spaces when copying. Don’t encode a string from the server panel a second time. If authentication fails, check the Method and Password pairing before changing DNS.
| Setting | Meaning | Common mix-up |
|---|---|---|
| Address / Port | Proxy server endpoint | Subscription URL or destination website |
| Method | Encryption and authentication format | Replacing a method just because its name looks similar |
| Password | Credentials required by that method | Extra encoding or whitespace when pasting |
| UDP | Datagram forwarding capability | Assuming UDP works after testing only TCP |
UDP, additional transports, and iOS behavior
Check the TCP and UDP paths for Shadowsocks separately. A webpage loading doesn’t mean datagrams for games or calls can get through. The client settings, server-side forwarding, and network along the way can all restrict UDP; the destination app may use different ports as well. If your server details include additional transport settings, make sure the current client offers the matching options and enter them exactly. The same base protocol doesn’t guarantee compatibility with the same additional transports.
On an iPhone, streamlined data packaging may reduce some processing overhead, but actual speed still depends on the encryption method, device, and network path. Processing costs are easier to notice during sustained, high-volume downloads; for occasional messaging, connection setup and waking the wireless radio may matter more. A simple protocol design doesn’t guarantee better battery life, and a peak from one speed test isn’t a measure of sustained throughput.
Troubleshooting can follow three branches. If the server endpoint always times out, check the hostname, port, and current network. If the connection starts and then immediately fails, check Method and Password. If webpages work but some apps don’t, check UDP, rule matches, and DNS resolution. If the entry came from Subscribe, keep a copy of the original values before making changes so a later update doesn’t overwrite them. This check order is usually more effective than flipping unrelated settings at random.
VMess and VLESS: authentication, transport, and TLS
One configuration can contain several layers
With VMess and VLESS, distinguish the protocol from the outer transport. A configuration may include UUID, TLS, WebSocket, Host, and Path settings, each with a different role. UUID identifies the user; transport settings determine how data is carried; TLS encrypts the relevant connection and verifies the server’s identity. Getting one value right doesn’t make up for a mismatch at another layer. In particular, a UUID alone doesn’t tell you which protocol an entry uses.
VMess has its own authentication and data protection mechanisms, and its configuration may include security method settings. VLESS has a more streamlined design and doesn’t treat built-in content encryption as a core function; it’s generally paired with an external security layer. Don’t reduce the difference to “complex is slow, streamlined is fast.” TLS and other transports may be layered on top, and handshake count, connection reuse, and server implementation all affect the actual overhead.
UUID, security method, and system time
Use the UUID assigned by the server exactly as provided. Don’t generate a new one or reuse another user’s identifier in this entry. Some VMess authentication flows depend on the time, so a device clock that’s significantly off can cause authentication to fail even when the settings look right. If this happens, let the system sync the date and time, then check whether the original server details are still valid. Correcting the clock doesn’t bypass authentication; it rules out a local time error.
Choose the VMess security method specified by the server. If an imported entry contains legacy compatibility settings, don’t change them to a fixed value based on a screenshot in another guide; server deployments can differ. A VLESS identity field also can’t replace the outer security settings. If an entry still shows VLESS after TLS is disabled, the protocol name doesn’t restore the missing encryption layer. Check the complete settings supplied by the server.
| Setting | Role | How to check |
|---|---|---|
| Address | Server endpoint used to establish the connection | Confirm it resolves and the port runs the expected service |
| Server Name / SNI | TLS handshake and certificate identity check | Match the server’s requirements and certificate name |
| Host | Request host used by some HTTP-based transports | Enter the value specified for the transport endpoint |
| Path | Request path for transports such as WebSocket | Check capitalization, slashes, and the full path |
WebSocket, TLS, and connection overhead
WebSocket first establishes an HTTP exchange, then carries subsequent data. When TLS is enabled, a secure handshake is needed as well. This can add several setup steps to the first connection, but an established, reused connection doesn’t repeat the whole process for every packet. If the first request is slow and later ones are faster, consider DNS caching, TLS session resumption, and connection reuse before assuming the protocol is unstable.
Address, SNI, and Host may be the same or differ depending on the deployment. Don’t force them to match. If Address is an IP, the certificate may still need to be verified against a domain name. Even a single incorrect character in Path can send a request to the server without reaching the intended proxy service. For certificate errors, check the name, validity period, and device time. Don’t make skipping verification a permanent setting.
On iOS, extra encapsulation can add connection setup work, while connection reuse can reduce repeated handshakes. When switching frequently between Wi-Fi and cellular, the underlying connection often has to be re-established; repeated reconnects over a short period can matter more to the experience than the cost of a single encryption operation. To compare VMess and VLESS, use similar server routes, the same outer transport, and similar workloads. Otherwise, you can’t attribute the results to the protocol itself.
Trojan, HTTP, and SOCKS5: different roles for proxy connections
Trojan requires TLS
Trojan combines proxy authentication with a TLS connection. The client must first reach the server and establish the appropriate secure connection; the server then checks authentication and forwards requests. That makes Password, server address, port, and TLS identity settings all essential. A correct password won’t help if the certificate name is wrong and the connection fails before authentication. A successful TCP connection to a port doesn’t prove that it’s running the expected Trojan service.
When setting up Trojan, Address specifies the connection endpoint, Server Name or SNI provides the name used for the TLS handshake, and Password is for proxy authentication. If the server uses a domain certificate but the endpoint is an IP, keep the corresponding name from the server details. Certificate validity, system time, and the trust chain can all affect verification. Don’t permanently skip certificate checks just to remove an error: doing so weakens server identity verification and can conceal a configuration error that needs fixing.
An HTTP proxy doesn’t mean you’re visiting an HTTP website
An HTTP proxy handles requests or establishes connections through mechanisms such as CONNECT. Type set to HTTP describes how the client communicates with the proxy; it doesn’t mean you can only visit HTTP websites. HTTPS destinations are generally reached through a tunnel. On the other hand, an HTTPS destination doesn’t mean every exchange between the client and proxy uses TLS. Check separately whether the proxy endpoint provides an encrypted connection and which layer protects the authentication details.
HTTP proxies are often used on existing organization networks or wherever an HTTP proxy endpoint is explicitly provided. Address, Port, Username, and Password should come from the same configuration. The server may treat an empty username differently from an omitted one. Whether the server allows CONNECT to a destination port or restricts destinations is part of its proxy policy. If one site works but another type of service doesn’t, check these restrictions rather than trying to fix the issue by changing destination DNS.
SOCKS5 authentication and UDP requirements
SOCKS5 defines how a client requests connections through a proxy and can include username-and-password authentication. SOCKS5 itself doesn’t encrypt the traffic it carries. Check the actual deployment to see whether another protected transport is in use. A SOCKS5 endpoint on a controlled network may serve a specific purpose, but a login password isn’t the same as an encrypted channel. HTTPS websites don’t remove the need to consider how other traffic is protected.
| Protocol | Key requirements | Common failure points |
|---|---|---|
| Trojan | TLS and proxy authentication both match | Certificate name, password, or port mismatch |
| HTTP | Endpoint accepts the required requests and destination ports | Incorrect authentication, CONNECT permission, or endpoint type |
| SOCKS5 | Server supports the required authentication and commands | UDP forwarding unavailable or authentication mismatch |
SOCKS5 UDP requires support from both the server and the network path. Even if TCP CONNECT works, UDP ASSOCIATE negotiation or subsequent datagrams may still be blocked. If the proxy returns a datagram address the client can’t reach, the control connection may succeed while the app fails. Check the UDP endpoint, returned address, and destination app separately; a successful TCP test doesn’t prove every feature works.
Understanding differences on iOS
Trojan’s TLS handshake adds some setup overhead, but an established connection can carry subsequent data. HTTP and SOCKS5 have more direct protocol exchanges, but that doesn’t guarantee a shorter route or faster speeds. For a meaningful comparison, use the same destination, server egress, and similar connection reuse conditions. If one protocol only works on the current Wi-Fi network, first check which transports and ports that network allows. Don’t treat a protocol as universally better or worse.
Choose based on what your existing endpoint supports, what your use case needs, and whether the security boundaries are clear. If you need TLS identity verification, check Trojan’s security settings. For an existing organization HTTP or SOCKS5 endpoint, use it within its stated permissions. For other common connection issues, see Troubleshooting. Changing Type won’t make the server support another protocol or change the access permissions on your account.
WireGuard: keys, addresses, and route prefixes
Why its settings differ from those of a typical proxy
WireGuard tunnels IP packets and uses a fixed set of modern cryptographic components with a relatively streamlined handshake. It doesn’t identify a peer through a username-and-password form; keys establish identity, and address ranges determine which traffic can go through that peer. When viewing a WireGuard entry in Shadowrocket, understand the keys, tunnel address, Endpoint, and AllowedIPs separately. Don’t apply the usual proxy setup pattern of “address plus password.”
PrivateKey is the local private key; PublicKey usually refers to the peer’s public key. Both look like encoded strings, but they represent different identities and directions. Don’t put the private key in the peer’s public key field or swap them because their strings are a similar length. PresharedKey is optional extra shared material; enter it only if both sides are configured to use it. Adding a value yourself won’t improve connectivity and may make the handshake fail.
Endpoint and tunnel address
Endpoint is the peer’s host and port for receiving UDP traffic. The tunnel Address is the address this device uses inside the tunnel. They belong to different layers: a reachable public endpoint doesn’t prove that the internal address is correctly assigned, and a correct internal address can’t make an unreachable endpoint port work. When entering details in the interface, keep the address prefix length and check IPv4 and IPv6 against the supplied configuration. Don’t replace them with a local network address of your own.
AllowedIPs determines which destination addresses go through a peer and which source addresses are accepted from it. A wider prefix covers more destinations; a narrower prefix covers only the specified subnet. It isn’t a regular website allowlist. Shadowrocket’s Global Routing, Config rules, and the system network extension also affect whether app traffic enters this entry. A full-range prefix alone doesn’t prove that every app is using the tunnel.
| Setting | Role | What must match |
|---|---|---|
| PrivateKey | Local identity | Must correspond to the local public key registered on the server |
| PublicKey | Peer identity | Use the current peer’s key, not the local public key |
| Endpoint | External UDP endpoint | Host, port, and reachability on the current network |
| AllowedIPs | Address ranges assigned to the peer | Cover the required destinations without misreading the route scope |
| MTU | Maximum packet size carried by the tunnel | Allow for the underlying path and encapsulation overhead |
MTU, keepalive, and mobile networks
MTU sets the maximum size of tunnel packets. If the underlying path can’t carry large encapsulated packets, small requests may work while large pages or uploads stall. Adjust MTU only after ruling out authentication and routing errors. Keep the original value and test changes gradually; a value that works on one network isn’t a universal setting for every device. If IPv4 and IPv6 take different paths, test them separately rather than judging by one webpage load.
PersistentKeepalive sends traffic at an agreed interval to maintain certain network address translation mappings; more frequent keepalives don’t necessarily make the connection more stable. Shorter intervals can increase background traffic and wake the radio, while longer ones may not suit the lifetime of some mappings. First confirm that the connection fails to resume after being idle, then adjust based on the server’s recommendations. On mobile networks, reachability, address changes, and app retry behavior can also affect recovery.
A successful WireGuard handshake confirms that the key relationship and some communication requirements are in place. Accessing an internal service also depends on peer forwarding, the return route, address assignment, and DNS. If the handshake works but there’s no application traffic, check AllowedIPs, the tunnel address, and the server’s return path before checking rule matches. For field-by-field details, see WireGuard settings explained. Hide private keys and real internal network details when sharing a question.
Hysteria2: QUIC, UDP, and bandwidth settings
Design goals and practical limitations
Hysteria2 carries proxy traffic over QUIC and is designed with throughput, packet loss, and varied network paths in mind. QUIC runs over UDP and provides secure connections and multiplexing, but application data may still need recovery after loss, and the underlying network doesn’t automatically allow UDP. Before choosing it, confirm that your existing server supports Hysteria2 and that the current client supports its required authentication and transport settings.
Compared with TCP-based options, Hysteria2 handles data recovery and congestion control at different implementation layers, which can lead to different behavior on some lossy or changing network paths. But using UDP doesn’t guarantee faster speeds. Some networks throttle UDP or restrict large datagrams, and the server’s egress or destination site may be the bottleneck. The protocol’s design only translates into a better experience when it suits the actual path and workload.
Endpoint, authentication, and TLS identity
Address and Port point to the server’s QUIC endpoint. Use the authentication value from your existing configuration. It may contain separators; don’t split it into a username and password for a different protocol based on guesswork. If you import it through Subscribe, first check that Type and all settings were parsed correctly. Similar historical names or the word Hysteria appearing in both formats don’t make their configurations interchangeable.
TLS identity verification still matters with QUIC. Server Name must match the server’s configuration and certificate requirements. With an IP endpoint, the certificate name may still be a specified domain. Certificate errors, authentication failures, and UDP timeouts occur at different stages and need different checks: verify the name and trust chain for certificate errors, credentials for authentication failures, and the endpoint and network path for timeouts. Blaming every issue on a bandwidth value will lead you away from the cause.
| Setting | Purpose | What to watch for |
|---|---|---|
| Address / Port | Establish a QUIC connection | Check the UDP path, not just the TCP port |
| Authentication credentials | Identify an authorized client | Copy the complete value; don’t split or re-encode it |
| Server Name | Verify the TLS peer’s identity | Match the server’s requirements and certificate |
| Upload / download bandwidth | Used in the corresponding rate-control settings | Check units and direction; use values suited to the actual connection |
| Additional settings | Match the server’s specified configuration | Set only when required by the supplied details and supported by the client |
Bandwidth settings don’t guarantee performance
If the client offers upload and download bandwidth fields, first check their units and direction. Mbps and MB/s aren’t the same unit, and upload and download values aren’t interchangeable. A larger number doesn’t increase the physical bandwidth available. In modes that use rate control, a target that doesn’t match the actual connection can worsen queuing, packet loss, or delays for other apps. Whether the field takes effect also depends on negotiation and server settings, so don’t treat an arbitrarily high value as a universal optimization.
On the same network, first measure a stable range, then enter values based on the server’s instructions. Also check webpage response times, sustained downloads, and call quality. A download peak alone can hide a significant increase in latency under load. Available capacity on cellular networks changes with signal and cell congestion, so fixed settings may not always be appropriate. Record the network conditions for each test and keep the original configuration that works.
iOS battery use and troubleshooting
Sustained high throughput, packet loss recovery, and user-space data processing can all increase processing and wireless transmission demands. Hysteria2 isn’t inherently more or less power-efficient. If the same task finishes sooner, it may spend less time keeping the wireless connection highly active; if the connection keeps reconnecting while idle, the result can be the opposite. To compare battery use, keep the workload and duration the same. Don’t compare one protocol during a large download with another during idle time.
If the handshake fails only on one network, first check UDP availability. If a connection is established but throughput remains unstable, check the network path, bandwidth settings, and server load. If only some apps fail, check routing and the destination protocol. Don’t change unrelated rules just to make Hysteria2 connect. For additional settings that aren’t in your server details, keep the defaults or ask whoever provided the configuration rather than copying parameters from an unrelated example.
iOS speed and battery life: how to run a fair test
Keep the network and test target consistent
Before comparing protocols on an iPhone or iPad, rule out differences in the test conditions. Use the same device, network, destination, and time window. Pause unrelated large downloads and wait for photo sync or system updates to finish. Note whether you’re on Wi-Fi or cellular, whether the device is warm, and whether Low Power Mode is on. If the signal changes significantly or the device starts thermal throttling, don’t compare that run directly with earlier results.
Control server conditions, too. If different protocols use different data centers or egress routes, the results describe two complete paths; they don’t prove the protocols themselves differ. Even on the same host, check for different bandwidth limits or concurrent load. If your only option is one existing subscription and you can’t get equivalent endpoints, focus on which entry works better for your use case instead of trying to create a universal protocol ranking.
Record connection, traffic, and routing separately
Connectivity Test is useful for an initial check, but its results depend on the test method. A basic connection check doesn’t cover the full destination service, while an HTTP-based test also depends on its target. Open the app you actually need and observe the first response, sustained transfer, and recovery after idle time. Note whether the failure happens during name resolution, connection setup, content loading, or after a network switch. That’s more useful than just writing “it’s slow sometimes.”
| Mode | Purpose | What to check during a test |
|---|---|---|
| Config mode | Handle requests using the current configuration’s rules | Check which rule and policy match the destination |
| Proxy mode | Send the relevant traffic through a proxy in this mode | Useful for isolating rule-related issues; still check the actual logs |
| Direct mode | Connect directly in this mode | Use to check the underlying network, not to prove the proxy works |
In Config mode, a destination matching DIRECT won’t tell you how fast the current proxy protocol is. Temporarily switching to Proxy can help distinguish a rule issue from a server issue, but note the mode change and restore your original settings when the test is done. Policy groups, DNS, and local connections may still affect a request. Check the connection logs to confirm the actual route instead of relying only on the highlighted server name.
How to measure battery use without misreading it
The system battery screen shows activity and attribution over a period of time; it isn’t a power meter for an individual protocol. Screen brightness, media decoding, app refresh, signal strength, and connection retries all affect power use. For a fair comparison, measure idle connections, browsing the same content, and downloads of the same size over fixed periods. Repeat the tests at different times if possible and note foreground and background activity. Don’t draw conclusions from a few minutes of battery percentage changes.
For idle connections, focus on background wakeups, keepalives, and repeated reconnects. For sustained transfers, look at time per task, data transferred, and device temperature. For mobile use, check recovery after switching between Wi-Fi and cellular. On Demand controls when a connection is established under specified conditions; it isn’t a speed boost. If its rules cause frequent connections and disconnections, battery use may change. Check the trigger conditions before attributing the difference to the protocol.
Test TCP and UDP separately, too. If webpages work but calls stutter, check the UDP path, jitter, or packet loss. If large downloads work but the first visit is slow, check DNS resolution or the handshake. If the first request fails after an idle period, check mappings, keepalives, and app retries. Recording these symptoms separately helps you choose the right next step without starting over by changing protocols every time.
Base your choice on repeated results, not a peak score. An entry that’s fast in one short test but often needs a manual reconnect may not suit everyday use. One with slightly lower sustained throughput but stable response and reliable recovery after idle may be better for messaging and work. This comparison is about fit for your current network and workload; it doesn’t guarantee the quality of any network service.
Choose for your use case: verify rules and troubleshoot end to end
Start with your needs, not the protocol name
For everyday browsing and apps, start with an entry from your existing details that’s complete and connects reliably. There’s no need to switch servers just to get a different protocol name. For internal networks and address routing, check the WireGuard peer and allowed subnets. For an organization’s HTTP or SOCKS5 endpoint, confirm its authentication and access permissions. If an app needs UDP, test that capability separately. If a requirement isn’t met, determine whether the cause is the configuration, server support, or a network restriction.
Keep the required transport and TLS settings for VMess, VLESS, and Trojan; confirm the encryption method and datagram support for Shadowsocks; and check the UDP path and rate settings for Hysteria2. Switching Type alone can’t make a protocol work with a server that doesn’t support it. If your existing subscription includes multiple types, keep the original entries and test them one by one. Don’t combine UUIDs, passwords, and transport paths to create a setup the server wasn’t configured to accept.
Make sure the rules actually use the protocol
Verify the protocol and the rules in separate steps. First, confirm the server works using a clearly defined test request. Then, in Config, check whether the destination uses the expected policy. The Shadowrocket .conf snippet below demonstrates rule matching order; it isn’t a complete configuration. Before using it, make sure your current configuration defines a working PROXY policy. The example domains are for illustration only and don’t identify services you should visit.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYRules are generally evaluated in order, and the matching rule’s policy is applied. DOMAIN-SUFFIX covers a domain and its subdomains. IP-CIDR specifies an address range. no-resolve prevents that rule from actively resolving a domain just to find a match; an already resolved destination address may still be checked. GEOIP uses an IP address database and doesn’t indicate which region a website belongs to. FINAL is the fallback rule and must come after rules that need to be evaluated first, or those rules may never take effect.
If a destination matches REJECT, the connection is blocked by the policy; changing protocols won’t fix it. If it matches DIRECT, first check whether that’s expected. For details on reject policies and how they apply to content on the same domain, see REJECT rules explained. Copy your configuration before changing rules so a test for one destination doesn’t change the paths used by other apps.
Narrow down checks based on the failure stage
| Symptom | Check first | Don’t change these yet |
|---|---|---|
| Endpoint always times out | Address, port, and TCP / UDP path | Rule details and app settings |
| Handshake or authentication fails | Protocol, credentials, TLS name, and device time | Bandwidth targets and test method |
| Connection succeeds, but destination won’t load | DNS, rule match, return path, and permissions | Changing the encryption method without evidence |
| Small requests work, but large transfers stall | MTU, path capacity, packet loss, and server load | Re-entering all authentication details |
| Fails after idle time or a network switch | Keepalive, mappings, reconnects, and On Demand | Assuming an intermittent issue means the protocol is always incompatible |
If access by domain name fails but a direct destination test works, check where DNS is resolved, the type of address returned, and how DNS requests are routed. Don’t treat every issue as a certificate verification problem. If only IPv6 networks are affected, check server endpoint, destination address, and tunnel address support separately. Once you have a working configuration again, add rules back one at a time to identify which change caused the problem instead of leaving behind a set of switches you can’t explain.
Keep conclusions you can reproduce
After troubleshooting, record the protocol and outer transport used, the tests that succeeded, and any remaining limitations. Remove experimental entries you no longer need. A Subscribe update can change server settings, and changes to the system network can invalidate earlier results. When a new issue arises, check the current details again instead of repeating old changes automatically. Configurations, QR codes, and logs may contain sensitive information. Review them carefully before sharing, and don’t publish an unredacted export.
To follow the setup steps again, return to the Getting Started Guide. For short answers organized by symptom, visit Troubleshooting. This manual helps you choose a type based on your server details and make changes for reasons you can verify, rather than relying on protocol names to judge whether connection requirements are met.