Shadowrocket
Protocol Types & Settings

Design and Limitations

Shadowsocks is designed to provide encrypted proxy forwarding with a relatively simple protocol: the client tells the server which destination to reach, and the server connects to it. It mainly relies on a password and encryption method agreed between the two sides; a website certificate is not a basic authentication requirement. This distinction helps clarify the fields: a standard Shadowsocks configuration requires both Password and Method. You cannot reuse a password from another protocol or assume two services are interchangeable just because they use the same port.

Different encryption methods may have different message formats and key requirements. Newer and older methods do not differ only in strength; they may also require different key formats, lengths or implementation support. Select the method specified by the server. If it is not available in the list, check whether the details are compatible with your client rather than choosing a similarly named alternative. After importing, confirm the method name, especially if the subscription was converted.

Check the Address, Port, Password and Method

Enter the server domain or IP address in Server and the actual listening port in Port. The address usually does not include a webpage path, and the port should not be entered in the address field. Copy Password exactly as provided, watching for spaces, line breaks and full-width characters. Method specifies the encryption method; it is not a personal preference. If the address resolves but the connection keeps failing, check both the port and method. A domain opening in a browser does not prove that the proxy port is working.

Some configurations include additional transport settings, but these are not required by every Shadowsocks service. Enable them only when your existing details specify them, and keep their names and values consistent. Do not add an option just because you saw it in another configuration; extra encapsulation changes the data format the server expects. If an imported entry behaves differently from one you entered manually, compare the fields while keeping the imported entry as a reference. This helps preserve the original details during troubleshooting.

Working TCP does not mean UDP is available

Most web browsing works over TCP, but real-time communication, some DNS lookups and apps using QUIC may involve UDP. TCP and UDP forwarding in Shadowsocks have separate requirements: the server must support the relevant capability, the network must allow that traffic, and the client must not have it disabled. If webpages work but real-time features do not, check this path. One successful page load does not prove the connection suits every app, and a single app failure does not mean the entire connection is down.

On iPhone and iPad, lightweight forwarding generally means fewer layers of encapsulation to consider, but it is not always faster or more battery-efficient. Chip performance, the number of long-lived connections and network retransmissions can all change the result. If the same configuration works on Wi-Fi but times out on cellular, first compare endpoint ports and network reachability. If performance drops mainly under heavy load, consider server load and sustained throughput; the protocol name alone is not enough to draw a conclusion.

Troubleshoot in four steps: check whether the details are complete, whether the endpoint is reachable, whether authentication matches, and whether the specific use case is supported. First check that the subscription updated, then confirm which entry is selected; otherwise, you may edit one entry and test another. For authentication errors, recheck the password and method. For timeouts, start with the address, port and current network. If only some requests fail, check rules and UDP. This keeps cause and effect clear instead of cycling through several settings at once.

If your server supports only Shadowsocks, use the complete matching configuration; there is no need to change the type just to try another protocol. If you already have multiple working configurations, compare webpage load time, sustained transfers and background idle behavior using the same destination and similar test times. It is more useful to record which part improved than to label a protocol “lightweight” or “fast”—and that makes it easier to reassess when network conditions change.

Keep Certificate Identity and User Password Separate

Trojan carries the proxy session inside a TLS connection. TLS first establishes a protected channel; protocol authentication and destination details are then sent through it. There are two separate identities: the certificate verifies the server you are connecting to, while Password proves that the client is authorized to access it. A correct password cannot fix a certificate name mismatch, and a valid certificate does not mean the server accepted the password. Troubleshoot in handshake order rather than treating every failure as a password problem.

This design relies heavily on TLS for security, making the server name, certificate validity period and device trust settings especially important. It does not mean you need to enter every TLS option manually; an existing subscription usually includes the required settings. Keep the imported configuration intact and use the error to identify what may be missing. Trying different names without complete details could connect to a different endpoint and make the failure harder to explain.

Server, Server Name and Certificate Chain

Server is the address the network connection actually reaches. Server Name is an important value used during the TLS handshake and name verification. When connecting by domain, they are often the same; when connecting by IP, you may still need the original domain as the Server Name. Certificate verification also depends on validity dates and the trust chain, so a correct name is only one requirement. If a certificate has expired or the intermediate certificate chain is misconfigured, the server needs fixing—not repeated changes to the client password.

An incorrect device clock, a network sign-in page or faulty DNS resolution can all cause TLS symptoms that look similar. On public Wi-Fi, requests may be redirected to a login page until you sign in; incorrect DNS results may also connect you to a certificate that does not belong to the service. First confirm that the network itself is working, then check DNS resolution and Server Name. Do not submit more credentials or expand the scope of trust before confirming which endpoint you have reached.

Authentication, Transport and Service Support

Preserve the exact case and symbols in the Trojan Password. Do not paste an entire subscription URL into the field. If your existing details specify an additional transport, it must also match the server; do not remove required fields just because a common Trojan setup uses a particular transport. After importing, check the type, address, port, password and TLS name, then review any other transport settings. This order helps catch common structural mistakes first.

UDP availability still depends on server support, client settings and network conditions. A protocol's ability to forward a type of traffic does not mean every app will behave the same way. Real-time apps are more sensitive to latency and jitter, while long downloads are more affected by server bandwidth. If webpages work but a real-time app does not, test that use case separately. Do not treat a successful page load as proof that the app works, or increase every timeout in an attempt to hide the issue.

Check Connection Reuse and Reconnection on iOS

A TLS handshake requires data exchange and computation, so the first connection has a different cost from subsequent stable transfers. In scenarios with frequent short-lived connections, the number of handshakes can affect responsiveness and battery use. For long-lived connections, that cost is spread out and link quality often matters more. Whether the client and server use connection-reuse mechanisms also affects the result. Record the first page load separately from subsequent visits; speed after a session is established does not represent a cold start.

Switching from Wi-Fi to cellular can change the device's address and network path, so existing TCP connections usually need to be re-established. If the connection does not recover, stop the current task, confirm that the new network works, and then measure reconnection time. Do not clear the configuration immediately. Repeated background connection failures can increase retries and keep the wireless radio active, raising battery use. Investigate the failure rather than assuming encryption is the cause.

If you already have a working Trojan configuration, keep its certificate verification and authentication settings intact during everyday use, and check that subscription updates have not overwritten them. To compare it with another protocol, use a similar network path, the same destination and the same test period, and make clear that you are comparing the whole service setup. Protocol guidance can help locate problems, but it cannot replace checking server status and destination reachability.

Understand That It Handles Network-Layer Traffic

WireGuard is designed as a network-layer tunnel, which differs from establishing a proxy connection to a particular destination. Along with the remote endpoint, its configuration needs a local address, key identities and the address ranges allowed through the tunnel. Managing it alongside other connections in a client does not remove these network-layer requirements. Use a complete configuration rather than trying to assemble one from a domain and password. Without the tunnel address or peer public key, the expected communication path usually cannot be established.

WireGuard uses public keys to identify peers. The local private key proves the local identity, while the peer's public key identifies the remote identity. These are not interchangeable strings. Keep the client private key secret, and make sure the server has the public key corresponding to that client; the server will not recognize a new key just because you entered it on your phone. If an administrator provided the configuration, keep the agreed key pair rather than generating a replacement and overwriting it.

Endpoint, Address and Allowed IPs

Endpoint is the network address of the tunnel peer, usually a host and UDP port. Address is the local address inside the tunnel, not the server's public address. In WireGuard's basic semantics, Allowed IPs relates both to destination routing ranges and to the addresses permitted for a peer; the client integration's exact behavior also depends on app settings. These roles help explain why a successful handshake does not guarantee access: it proves that the peers established a session, not that every destination has a correct route.

For access to an organization network, the destination subnet must match the supplied configuration, and the server needs a forwarding and return path. If the local Wi-Fi subnet overlaps with a remote internal subnet, routing may become ambiguous. Changing keys repeatedly will usually not help; first check where traffic to the destination is routed. For IPv6, verify that the necessary addresses and routes are configured. IPv4 working does not mean the IPv6 address space is also available.

Keepalive and Mobile Network Trade-offs

WireGuard uses UDP. When a mobile device reaches a remote endpoint through a NAT device, an idle mapping may expire. One purpose of Persistent Keepalive is to maintain that mapping with periodic packets; it does not increase bandwidth. More frequent keepalives mean more wireless activity, while less frequent ones may delay recovery from idle on some networks. Follow the existing configuration and investigate the interval only if idle recovery is a real problem. There is no single fixed interval that suits every phone.

A network change may alter the underlying public address. WireGuard can adapt to peer address changes when conditions allow, but the experience still depends on UDP reachability, NAT and server policy on the new network. If Wi-Fi works but cellular does not, compare UDP reachability first, then check carrier network and peer restrictions. Address-update mechanisms do not guarantee uninterrupted service through every network change, and one fast recovery does not mean every network will maintain the session.

Test MTU and DNS Separately

Tunnel encapsulation uses some of the packet size. If the effective path size does not match the MTU setting, small requests may work while large responses stall. Packet loss or server issues can cause similar symptoms, so save the original value before making changes, change only one setting at a time and repeat the same request. Do not treat an MTU value found online as universal or immediately reduce it drastically when a webpage fails; that can needlessly reduce throughput.

DNS resolves domain names to addresses; routing determines where the data goes. They often come up together in tunnel scenarios but have different roles. If a known internal address is reachable but its hostname is not, check internal DNS and its network path first. For access to an internal network, a complete address plan matters more than protocol speed tests. For regular web browsing, verify that requests are actually using the expected Shadowrocket policy.

Establish a Baseline with the Same Tasks

Protocol comparisons should answer a real-use question. For everyday browsing, check the first response and subsequent page loads. For large file transfers, measure sustained throughput and interruptions. For real-time communication, check latency, jitter and UDP. For internal network access, prioritize address planning, DNS and the return path. If you already have multiple configurations, start with one that completes the task as a baseline. If they all fail, check the network and destination before drawing conclusions about protocols.

For a meaningful comparison, keep the device, network, destination, routing mode and test time as consistent as possible. Pause background traffic and note whether each connection is a first-time connection. Repeat each test a few times and use typical results, not the best run. Connectivity Test can help identify entries that are clearly unreachable, but it does not represent the full webpage experience and cannot confirm that UDP, internal network access or long-lived connections work. Separate connection checks, real usage and sustained transfers to identify where the difference occurs.

Use the Three Global Routing Modes to Isolate Variables

Config applies the rules in the current configuration to determine how connections are handled. Proxy sends eligible traffic through the proxy path; Direct connects without one. If Config fails but Proxy works, check rules and policy targets before changing the password. If both modes that require a proxy fail, check the endpoint, authentication and transport. A Direct test only provides a baseline for the local network: if the destination is unreachable directly, that alone does not prove there is a proxy protocol issue.

The example below shows a basic structure: choose a policy by domain suffix, connect directly for an IP range, and use a final rule for other requests. This is Shadowrocket .conf rule content, not a server configuration, and it contains no authentication details. PROXY must refer to a valid policy in your configuration. Back up the file before importing or editing, and confirm that the active Config is the file you changed. Rules are generally matched in order, so a broad condition near the top may prevent a more specific one below it from taking effect.

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

Domain rules rely on the client having domain information at the relevant point; IP rules match addresses. They are not interchangeable. A website may use multiple resource domains, and an app may connect directly by IP, so routing the main page as expected does not mean every related request follows the same policy. GEOIP results also depend on the address database and changes to destination addresses. To route only selected sites through a proxy, see the guide to routing selected sites through PROXY, then add conditions for your own destinations.

Match the Symptom to the Layer

For a complete timeout, start with the network, address and port. For an explicit authentication error, check the password, UUID or key pair. For a TLS error, check system time, Server Name and certificate. If the handshake succeeds but the service does not work, check destination reachability, DNS, UDP and routing. If only one domain fails, test another known destination. If all domains fail but a known IP is reachable, focus on DNS. Change one group of settings at a time, verify the result and record it; do not put several guesses into the configuration at once.

Keep Reproducible Notes Before Switching Protocols

Troubleshooting notes should include the device network, destination type, Global Routing mode, failure stage and conditions. Do not expose a full subscription URL, password or private key. Before sharing a screenshot or text, remove authentication details and personal identifiers; keep only the protocol type and non-sensitive fields needed to reproduce the issue. After a subscription update, compare the type, transport and name fields if needed, but retain the original entry so you do not lose a working baseline before confirming the new settings.

Choose based on compatibility and reproducible results: completing the task, recovering after a network change and running without repeated retries are more useful indicators than a single peak test result. For common import and connection issues, see Quick Start troubleshooting. For interface terms, see the quick reference; for feature behavior, see Feature Guide. If the issue concerns server authentication, certificates or routing scope, check those settings with the source of your existing details rather than repeatedly changing unrelated client options.