Shadowrocket Protocol Guide
Settings, Speed & Battery Life

01 / CONNECTION LAYERS

Connection layers: the roles of protocols, transports and rules

Start by separating four questions

Choosing a protocol type in Shadowrocket answers one basic question: what format should the client use to communicate with the server? Types such as Shadowsocks, VMess, VLESS and Trojan define aspects of authentication and data encapsulation. TCP, UDP and WebSocket describe how data is transported. TLS establishes an encrypted, authenticated channel, while rules determine which requests use that channel. These layers can work together, but they are not interchangeable. Changing the type name alone does not reconfigure the remote server to provide that service.

For example, a configuration with a server address, port, UUID, WebSocket path and TLS server name is not five separate protocols. It describes one connection across several layers. The client locates the server, establishes transport as specified, completes any required security handshake and authentication, then forwards the request. A mismatch at any layer can look like the same generic “connection failed” error. Before troubleshooting, note how the configuration is structured rather than switching types based on an error message.

Protocol names alone don't determine speed or battery use

Loading a webpage involves DNS lookup, connection setup, a handshake, data transfer and app processing. Short requests are often more affected by latency and handshake time; long downloads depend more on available bandwidth, packet loss and server load. A configuration that achieves high throughput on a download may not load many small pages faster. A low result in one test also doesn't prove the protocol is a poor fit for the device. Compare the same destination on the same network, at similar times, and repeat the test. Record failures as well as the best result.

On iPhone and iPad, battery use is also closely tied to wireless conditions. Weak signal, repeated retransmissions, reconnecting after drops and frequent background wake-ups can matter more than the encryption algorithm itself. Switching between Wi-Fi and cellular may require existing connections to recover; transport designs handle recovery differently, but that doesn't support a fixed battery-saving percentage. Stabilize the connection first, then compare battery use and heat over the same period of use. There is no single protocol that's always the most power-efficient.

Choose based on what is available

Choose in this order: check which types the existing server offers, confirm that the current network supports the required transport, then compare how each option works for your use. If the server provides one confirmed configuration, importing it intact is usually more reliable than manually changing it to another type. If several configurations are available, keep the original and create clearly named test entries. Change one variable at a time. Entries with different server addresses and credentials aren't a controlled comparison of protocol alone.

In the following sections, distinguish what a protocol can support from what the current server actually has enabled. Optional features only work when both implementations and configurations support them. A subscription may omit default values or use abbreviated names from a sharing format; check the source's documentation if a field is unclear. Don't guess by deleting unknown fields, and never post a complete configuration containing credentials publicly. For the steps to connect, return to the Getting Started guide. For help identifying an error, see the FAQ.

02 / SHADOWSOCKS

Shadowsocks: check the encryption method and password together

Designed as a lightweight proxy protocol

Shadowsocks was designed to forward proxy traffic between a client and server with relatively little overhead. Unlike a full network tunnel, it typically doesn't assign the device a virtual address and routing relationship first; it encapsulates individual destination connections. This helps explain why its core settings are often the server, port, encryption method and password, rather than a set of tunnel subnets. Performance still depends on the server implementation, network quality and method in use. A shorter configuration doesn't guarantee higher speed.

Many modern configurations use authenticated encryption, which lets the receiver decrypt data and detect tampering or a key mismatch. Methods differ in key requirements, data format and implementation, and similar names don't imply compatibility. Select the method specified by the server. Don't replace an existing method just because another name sounds newer; after a change, confirm that the password still meets the new method's format requirements.

Check these four core settings in order

First, check the server address for extra spaces, a protocol prefix or a path. The address field usually takes only a hostname or address, with the port entered separately; pasting an entire share link into the address field is not a substitute for importing it. Then check that the port belongs to this service, since one server may use different ports for different protocols. Finally, verify the encryption method and password. Preserve capitalization and trailing characters, and don't remove symbols that look unusual.

Some newer methods have specific key-format requirements; a memorable password and an encoded key aren't interchangeable inputs. If the server details include multiple keys or other identity material, import them as instructed by the provider instead of combining them yourself. When an existing subscription identifies the type correctly, preserve its field relationships. For a manual entry, start with the required settings and confirm the connection before exploring optional fields. This avoids introducing several unverified changes at once.

Check UDP support separately. Some apps send UDP requests, but the server must handle them, the network path must allow them, and the client must support forwarding them. A working webpage only shows that some TCP requests succeeded; it doesn't confirm that calls, real-time interactions or other UDP use cases work. Likewise, a real-time app failure doesn't prove the password is wrong. First distinguish an authentication failure from a failure affecting a particular traffic type.

Assessing performance on iOS

On iOS, encryption costs during sustained transfers depend on processor capability, the method's implementation and traffic volume. For everyday browsing, connection setup and wireless activity may have a greater effect; with large transfers, encryption work and sustained radio use are easier to notice. Test short page loads, sustained transfers and recovery after locking the screen separately. Don't rely on a single download. If the device gets warm, first check for simultaneous backups, media processing or app updates rather than attributing all activity to the proxy protocol.

If the connection fails, restore the complete original settings, check that the system time and network are correct, then retest the same configuration on another network. If every request fails, focus on the address, port, method and password. If only some destinations fail, check the rules, DNS and destination. Don't cycle through encryption methods at random, and don't mix temporary test copies into the subscription you rely on. Add clear notes to manual entries to avoid selecting the wrong default server later.

Shadowsocks is a suitable choice when an existing server explicitly provides a matching configuration and tests confirm it works for your needs. Its concise settings make individual fields easier to check, but none should be assumed optional. If the configuration requires a plugin or another form of encapsulation, confirm that the current interface supports it; don't dismiss a missing requirement as an unimportant note. Keep a working configuration you can reproduce, not just a protocol name.

03 / VMESS & VLESS

VMess and VLESS: understand authentication, encryption and transport separately

You can't switch between these protocols by changing the type alone

VMess and VLESS often appear in configurations with multiple transport options, but they aren't display aliases for the same protocol. VMess includes authentication and data-protection design at the protocol layer. VLESS has a leaner protocol layer and is often paired with a separately configured secure transport. Both commonly use UUIDs as identity values, which can make them look interchangeable. They aren't: the server must run the corresponding protocol and accept the same transport combination, even if the UUID looks identical.

A UUID is a structured identifier, not a server address or the name used to validate a website certificate. Check that it is complete, contains no extra spaces and belongs to the server you're configuring. Don't mix UUIDs, ports and paths from different configurations. VMess authentication also involves time conditions, so a significantly incorrect device clock can cause failures; set the system time automatically. This addresses clock issues, not an incorrect identity or transport setting.

Check transport settings as a group

A typical configuration specifies a transport such as TCP or WebSocket in addition to the protocol. For WebSocket, the path must match the server endpoint; slashes, capitalization and query parameters can all matter. Host is generally used in the application-layer request or frontend routing, while the TLS server name is used for the security handshake and identity verification. They may match, or differ depending on the deployment. The server address, Host and TLS name serve different roles; don't force them to the same value just to make the form look consistent.

When a domain routes through multiple layers, reaching the frontend port doesn't prove that the request reached the correct protocol service. A wrong path may return a normal webpage; a wrong Host may route to another site; an incorrect TLS name may be rejected earlier in the connection. A reachable port confirms only the first layer. Check the address and port, TLS, transport path and protocol authentication in order. An “online” server can still have a configuration problem.

Don't treat VLESS itself as a general substitute for payload encryption. To protect traffic between client and server, confirm which security layer the configuration actually uses and how it verifies the connection. Some configurations also include flow-control or handshake settings; these aren't general-purpose speed switches and only work when both ends agree on the same combination. If a field isn't visible in the current interface, first check whether that combination is supported. Don't put an unknown value in a note or unrelated field as a workaround.

The limits of connection setup overhead and multiplexing

On iPhone, the first connection may be affected by network round-trip time, the TLS handshake and extra transport encapsulation. There's no reliable basis for simply ranking VMess and VLESS by speed: server distance, transport and connection reuse can all change the result. Reuse may reduce the cost of repeatedly establishing connections in some scenarios, but it also puts multiple requests on one underlying channel. When congestion occurs, sharing a channel isn't always smoother. Test the same workload instead of enabling every optional setting by default.

Battery comparisons also require controlled conditions. If a configuration repeatedly fails authentication after a network switch, the repeated handshakes may increase background activity. Fixing the path, clock or credentials is more direct than switching to a protocol that sounds lighter. If only the first request is slow after reopening the app, distinguish normal connection recovery from repeated retries. Note the recovery time, whether a manual switch is needed and whether the error recurs. Don't treat a single observation as a defining trait of the protocol.

If an existing VMess configuration is complete and stable, there's no need to migrate just because another type looks more lightweight. With an existing VLESS configuration, focus on how secure transport, authentication and optional flow control fit together. When maintaining multiple test entries, note their transport and purpose rather than rewriting server-provided protocol settings. For help selecting the default entry and running Connectivity Test, see First Connection and Testing.

04 / TROJAN & TLS

Trojan: check TLS identity verification separately from the protocol password

Proxy requests carried over an established TLS channel

Trojan's key design choice is to use TLS for encryption and server identity verification, then handle protocol authentication and request forwarding within that channel. Understanding it requires more than checking the password field: you also need to understand the relationship between the certificate, server name and connection destination. TLS is a widely used security mechanism, but a server supporting TLS doesn't automatically accept Trojan requests. The client must still connect to the correct port and provide the right credentials to a server that supports this protocol.

The server address tells the client where to connect; the port identifies the service. The TLS server name is sent during the handshake and used to verify the certificate identity. The certificate must cover the name being verified and be within its validity period, and its certificate chain must be trusted by the system. If connecting directly by address when the certificate was issued to a domain, specify the correct verification name as the configuration requires. Resolving to the same machine doesn't mean a certificate can validate any name: the same network destination does not imply the same identity.

A failed handshake doesn't necessarily mean the password is wrong

Authentication usually occurs after the secure channel is established. If the certificate is expired, the device time is wrong, the name doesn't match or the server can't provide a complete certificate chain, the connection may never reach password verification. Re-entering the password won't fix a TLS failure. First check the system date, domain spelling and certificate-related messages, then ask the maintainer of your existing server to verify its certificate setup. If TLS succeeds but protocol authentication is rejected, focus on the password, service type and server-side permissions.

Copy the complete password, preserving capitalization, special characters and every character at the beginning and end. If a subscription update changed the password, an old manual copy may no longer work; check that you've selected the updated subscription entry rather than an older one with a similar name. Don't include notes in Chinese, quotation marks or line breaks as part of the password. You can note that the password was checked against its source, but don't include the actual password in a public screenshot or log.

Some configurations specify ALPN or other TLS negotiation requirements. ALPN negotiates the application-layer protocol; it's not a speed setting to choose at random. Whether it's required and which values are accepted depends on the server. Don't copy a value from elsewhere just to fill in the form. If the subscription already includes these fields, preserve them as a set. When something goes wrong, compare each field with the original instructions instead of clearing every security option at once.

TLS handshakes and connection recovery on iOS

Establishing TLS for the first time requires a handshake, so network round-trip time affects setup. Once a connection is established, throughput also depends on the transport path, congestion and server load; the time to load a page initially isn't the same as sustained speed. Session resumption may reduce the cost of later handshakes when conditions allow, but whether it happens depends on the implementation and server state. Compare the first visit with an immediate repeat visit, and don't mistake caching for a protocol change.

After switching from Wi-Fi to cellular, an existing connection may need to be rebuilt; a short wait doesn't necessarily mean the credentials are invalid. If recovery fails for a long time each time, check whether the current network can reach the server port and resolve its address. For battery use, repeated TLS setup, retries and retransmissions over a weak signal are more worth investigating than a stable long-running connection. Eliminate failed retries first, then compare normal use. Don't assign a fixed battery cost to one handshake mechanism.

Trojan is a suitable choice when your existing configuration specifies this type and includes the TLS name, certificate and authentication details. Troubleshoot in a clear order: confirm the destination, validate the secure handshake, then check the password and request. If a webpage still fails after a connection test passes, continue checking DNS and rules; using TLS doesn't bypass the other layers. For mode selection, see The Three Global Routing Modes.

05 / HTTP & SOCKS5

HTTP and SOCKS5: a proxy interface isn't an encrypted channel

How these general-purpose proxy protocols are designed

HTTP proxies were designed for application-layer proxying. They handle suitable HTTP requests and commonly use CONNECT to establish a byte tunnel to other destinations. SOCKS5 provides a more general connection negotiation method: the client specifies the destination to the proxy, which then establishes the connection. Both are proxy interfaces, but the interface alone doesn't tell you whether the client-to-proxy connection is encrypted or whether the proxy supports every request type. Check transport security, authentication and server capabilities before choosing.

A common misconception is that HTTPS on the destination website protects every leg of the connection to the proxy. The destination site's TLS can protect application data in the tunnel, but it doesn't automatically give the HTTP proxy's CONNECT negotiation or proxy authentication the same protection. If you connect to the proxy over TLS, its certificate must also be verified. “The destination uses HTTPS” and “the client connects to the proxy securely” are separate claims; don't treat them as interchangeable.

Addresses, credentials and where DNS happens

When setting up an HTTP or SOCKS5 entry, first confirm the server type, then check the address, port, username and password. The server may allow access without a username or require authentication; whether fields can be left blank depends on the original configuration. Username and password are separate fields, so don't paste a delimited string into either one. Some deployments restrict access by source network; even correct credentials may be rejected on cellular. Ask the maintainer of your existing server to confirm the access requirements.

Where DNS resolution happens can affect results. The client may resolve a domain to an address before sending a request to the proxy, or the protocol may allow the domain to be resolved by the proxy. Actual behavior depends on client settings, protocol capabilities and server implementation. The two paths may return different addresses, especially when a service assigns addresses based on the request's location. If a domain fails but an address appears reachable, check the resolution path and result before changing proxy types. Testing HTTPS by address can introduce a certificate-name mismatch, so it's not an equivalent test.

SOCKS5 defines a UDP association, but not every deployment enables it, and the protocol name alone doesn't confirm it's available in your configuration. The server may handle only TCP, or a firewall may block UDP responses. HTTP CONNECT is commonly used to establish a TCP tunnel; don't assume it supports the same UDP association as SOCKS5. For real-time audio or video, test the required traffic rather than inferring support from a webpage loading successfully.

Use cases and iOS behavior

If your workplace network, lab environment or self-managed server provides a general-purpose proxy interface, HTTP or SOCKS5 may fit the existing service. Choose based on interface compatibility, not which name sounds more advanced. The absence of extra encryption doesn't make it suitable for sending sensitive credentials over every network. First understand where the connection is protected and where it isn't. Don't share plaintext credentials as routine troubleshooting details or repeatedly submit them when you don't know whether access is permitted.

On iOS, the speed of either interface also depends on proxy distance, connection setup and destination response. Less protocol overhead doesn't necessarily compensate for a poor route or guarantee lower battery use. If apps behave differently, first check whether they use different destinations, transports or DNS paths. If TCP tests pass but real-time features fail, check UDP support. Focus on the username and password only when authentication fails, rather than changing unrelated settings repeatedly.

For each general-purpose proxy, record three things: whether the connection to the proxy is protected, which transports it supports, and which side resolves domain names. Only then can you decide whether it suits your needs. If you know only the address and port, check the rest with the source of the original configuration rather than guessing security settings. This separates a working interface from one that's appropriate for your use and helps prevent unexpected results.

06 / WIREGUARD

WireGuard: consider keys, tunnel addresses and routing together

A network tunnel, not an individual proxy request

WireGuard is designed as an encrypted network tunnel, using peers, public and private keys, and routing ranges to establish communication. Unlike protocols that specify proxy destinations one by one, it routes packets through a virtual network path. This is why its settings often include tunnel addresses, a peer's public key, an endpoint and allowed address ranges. The distinction matters: a successful handshake with the endpoint doesn't prove that application traffic has a correct route. Correct keys can't replace server-side forwarding and return-path configuration.

Each peer has its own private key and uses the other peer's public key to identify it. Keep the client private key in your own configuration; use the server's public key as provided. Don't swap them. An optional pre-shared key adds shared key material to the existing key relationship; it's not another name for the private key. Entering a key on the client won't help if the server isn't configured with it, and will instead cause authentication to fail. Preserve the complete key relationship after import; don't mix keys from separate configurations.

Different roles of the endpoint, addresses and AllowedIPs

The endpoint is the location used to reach the peer over the public network, usually a domain or address plus a port. A tunnel address is an identity and address used inside the encrypted network; it shouldn't be set to the endpoint's public address. AllowedIPs affect both peer address constraints and route selection, though their scope in a particular client depends on how the app integrates them. They aren't an ordinary allowlist that can be expanded at will without affecting other traffic.

If the routing range is too broad, traffic that shouldn't use the tunnel may be sent through it. If it's too narrow, the destination subnet may have no route. The server must also know how to return traffic to the client, so forwarding, internal subnets and access controls need to agree. If the handshake succeeds but a destination is unreachable, first determine whether one internal subnet or all traffic is affected. Then check the address ranges and return path instead of generating new keys.

Check DNS separately. Reaching an address inside the tunnel doesn't prove that an internal domain can be resolved; if the configuration specifies an internal DNS server, that server must itself be reachable. Conversely, a domain resolving only proves that it returned an address, not that the destination's service port is reachable. Record DNS results and destination connection results as separate steps rather than summarizing both as “the network works.” For IPv6, also confirm that the address family and routes are fully configured.

UDP, keepalives and MTU trade-offs

WireGuard carries the tunnel over UDP, so the current network must allow data exchange with the endpoint. It can accommodate endpoint changes in some circumstances, but recovery still depends on network mappings and server reachability. Some environments need periodic keepalives to maintain a NAT mapping. Keepalives send packets regularly, so don't shorten the interval without a reason. On iPhone, especially when locked or on cellular, extra wake-ups can affect battery use. Use only the behavior required by the server configuration.

MTU sets the maximum packet size the tunnel can handle. Encapsulation adds overhead, and if the path can't carry larger packets reliably, small requests may work while larger transfers stall. But other issues can cause the same symptoms, so don't change MTU just because a download is slow. Keep the original value, check whether packet size is relevant, then test adjustments against server and path conditions. If a configuration is shared across devices, don't assume a value that works on one device is right for every network.

To assess WireGuard on iOS, observe sustained transfers, long periods of inactivity and recovery after a network switch separately. Its cryptography and handshake are designed to be lightweight, but signal quality and keepalive behavior may dominate battery use. A test without periodic background traffic isn't directly comparable to one with sustained transfers. If you need access to an existing internal subnet, first verify subnet coverage and DNS. For general request forwarding, also understand how WireGuard fits with Shadowrocket's current rules.

Choose WireGuard when you have an existing tunnel configuration and a clear access goal, not just because one throughput test looked good. When recording a problem, note whether the endpoint was reachable, whether the handshake completed and which address ranges failed. Never include the private key in public material. Before migrating a configuration, check whether the server permits the same identity to be used in that way. Two devices using the same configuration can cause connection changes that are hard to reproduce.

07 / HYSTERIA2

Hysteria2: confirm the UDP path before comparing throughput

Trade-offs designed around QUIC and challenging network conditions

Hysteria2 uses QUIC for transport. QUIC runs over UDP and uses modern secure handshake mechanisms. Its design aims to maintain transport efficiency under certain conditions involving packet loss, latency and bandwidth, while carrying proxy requests. That doesn't make it faster on every network. UDP reachability, network limits on UDP traffic, server load and congestion control all affect results. Confirm that the network supports the transport before comparing throughput.

QUIC can carry multiple streams on one connection, which can reduce some transport-layer head-of-line blocking. All streams still share the same network path and congestion budget. On a wireless network with severe packet loss, any reliable transport has to recover lost data; no protocol can create more available bandwidth. Good performance during a sustained transfer also doesn't guarantee faster initial responses for every short request. Distinguish “may help in certain conditions” from “always performs better,” and don't judge by protocol name alone.

Check authentication, TLS and optional obfuscation separately

When setting up a configuration, the server address and port locate the endpoint, authentication details establish access, and the TLS server name and certificate verify the remote identity. If the original configuration also requires an obfuscation type and password, both ends must use matching settings. An obfuscation password isn't another name for the authentication password, and shouldn't go in the certificate-name field. If any required details are missing, check the existing subscription or server instructions rather than borrowing assumptions from another protocol.

Certificate verification follows the same principles as other TLS configurations: the name must match, the certificate must be valid and the device clock must be accurate. UDP reachability is only a transport prerequisite; it doesn't prove that the secure handshake or authentication succeeded. If the connection recovers after a network switch, check whether the new path still allows data exchange on the same port. If it fails on every network, check the server status and settings. QUIC is no reason to skip certificate checks or dismiss a handshake error as ordinary latency.

Some deployments require upload or download bandwidth settings. These values may affect congestion control and sending behavior; they're not decorative numbers or a way to remove limits by entering an arbitrarily high value. Follow the server's instructions and use realistic link capacity, paying attention to units. Mobile bandwidth varies with location and signal. Overestimating it can increase queuing, packet loss or competition with other apps; underestimating it can restrict throughput. Test carefully under stable conditions.

Test speed, heat and network recovery separately on iPhone

For a sustained download test, use content of a similar size from the same source and record the completion time and any interruptions. The first few seconds of throughput can be affected by caching, burst sending and wireless scheduling. Background transfers also make results less representative. Afterward, check everyday page loads, messages and media requests. Don't sacrifice real-world stability for large-file throughput or treat a single successful test as proof of long-term reliability.

Higher throughput may shorten a transfer, but sustained high load can also increase processor and wireless activity; the result depends on the workload. On a poor network, retransmissions and repeated handshakes can change power use. Compare the time, heat and battery change for the same task instead of measuring only how much data was sent per unit of time. Short-term battery percentage readings are too coarse for precise protocol energy claims. Use them to observe trends, not as a measuring instrument.

QUIC includes connection migration features, but recovery still depends on both implementations, network mappings and path changes. Don't assume a switch from Wi-Fi to cellular will never interrupt a connection. Under controlled conditions, switch networks once and observe whether existing traffic recovers and new requests succeed. If only an existing session is interrupted, consider how the app itself handles recovery. Avoid switching back and forth rapidly, which makes it hard to identify when a failure occurred.

Try Hysteria2 when an existing server provides a matching configuration, the UDP path works and your use case warrants comparing its transport performance. For light browsing, stability and recovery time may matter more than peak speed. Keep a known-working configuration as a baseline, test one setting at a time, then decide what to use day to day. Don't change multiple values just because they sound performance-related when you have no measurements to guide you.

08 / VERIFICATION & DIAGNOSIS

Putting protocol selection into practice: from settings to rules

Start with a baseline you can restore

Before troubleshooting, keep the original subscription entry or a copy of the manual configuration, and note the current network, default server and Global Routing mode. Confirm that the subscription updated successfully, and distinguish its original entries from older manual ones; identical names don't guarantee identical settings. Then select the server to test in Home, complete any required authorization and run a connection test. Test one clearly identified entry at a time to avoid changing one setting while testing a different server.

The three Global Routing modes are Config, Proxy and Direct. Config handles requests according to the current rules; Proxy sends applicable traffic through the selected proxy route; Direct connects directly. These modes change how requests are handled, not the server protocol. You can temporarily compare modes while troubleshooting, but restore the intended mode afterward. If Direct also fails, check the device network and destination before changing the proxy password.

Identify the earliest layer where the failure occurs

First check whether the server address resolves correctly and whether the current network can reach its port. Then check TLS or another security handshake, verify protocol authentication, and finally investigate the destination request and rules. Prioritize the earliest failing layer; later layers can't yet be evaluated reliably. For example, a failed certificate handshake says nothing about whether proxy authentication works. Successful authentication doesn't prove that an internal subnet has a correct return route.

Connectivity Test can confirm a particular kind of connectivity for the selected entry, but it doesn't cover every destination, address family or app behavior. If the test passes but a webpage fails, continue checking DNS, the destination certificate and routing. If it fails, check whether actual traffic also fails before assuming there's a protocol problem; the test destination itself could be the issue. State what the test covered instead of claiming that one successful result proves everything works.

Test rules separately from the protocol

The examples below illustrate rule structure in a Shadowrocket configuration file; they contain no server details, authentication data or usable subscription. The domains are examples; review each rule for your own use before deploying. Rules are matched in order, so an earlier match affects later handling. The final FINAL rule handles requests not matched earlier. PROXY and DIRECT are actions, not server protocol names or commands that convert a connection to another protocol.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

If a destination works in Proxy mode but fails in Config, check which rule handles it, whether DNS returns the expected result and which proxy route the configuration selects. Don't immediately replace the protocol; the two tests may not use the same route at all. GEOIP matches against an IP-location database and isn't a direct substitute for specific domain intent. When domain and address rules coexist, check their order and DNS conditions rather than looking only for a particular keyword.

Choose based on the use case: for everyday browsing, consider initial response and stability; for sustained transfers, completion time and retransmissions; for real-time use, UDP support and latency variation; for internal network access, routing ranges and DNS. Protocol comparisons only make sense when your existing server provides multiple working options. There is no fixed ranking for every network and use, and a short-term test can't establish that a protocol is always better or worse.

When asking for help, note the protocol type, transport, network where the problem occurred, failure stage and individual tests already tried. Hide passwords, UUIDs, private keys and subscription identity details; share only the configuration structure needed to diagnose the issue. For common symptoms, see the FAQ. To review the steps from import to connection, return to the Getting Started guide. A working configuration you can restore and reproduce is more useful than trying every protocol in turn.