How to choose: understand the five layers
Names such as SS, VMess, and Trojan in a Clash configuration describe how proxy endpoints authenticate, encapsulate, and forward data. They don’t tell you how app traffic enters the client. A browser can use the system proxy, an app can connect to a local SOCKS port, or TUN can route system traffic through the client. These entry points change what gets routed, but they don’t turn one server-side protocol into another. Start by separating the local entry point from the remote protocol so you don’t mistake a routing issue for a protocol performance problem.
Evaluate the client UI separately from kernel capabilities
The client handles subscription management, proxy group controls, system proxy settings, and permission requests. The kernel parses configuration, matches rules, resolves domains, and establishes outbound connections. Seeing a protocol name in the UI doesn’t mean the running kernel supports every extension. Conversely, the kernel may understand a field that the client’s editor doesn’t yet expose. When checking support, note the client name, the kernel actually running, and the node’s transport combination.
A protocol name may be combined with transport and security layers. VLESS, for example, can use different transports and may be paired with TLS or REALITY. With VMess, distinguish protocol authentication from the outer transport. Comparing only two nodes’ protocol abbreviations overlooks important parts of the connection path. Server location, route distance, carrier peering, egress congestion, and server-side limits can all matter more than the protocol’s processing overhead.
Connection time, time to first byte, and sustained throughput are different metrics
Connection setup time includes DNS resolution, transport handshakes, authentication, and any security handshake. A webpage’s time to first byte also depends on the destination’s response and rule processing. Large-file throughput depends more on congestion control, bandwidth, and server capacity. One protocol may connect slowly at first but perform steadily once a connection is reused; another may handle short requests quickly but hit a server-side rate limit during a long download. Define what you’re testing instead of relying on a single latency figure in the client.
UDP support needs to be checked at every layer. A node that supports UDP forwarding doesn’t mean the app’s traffic entered the proxy over UDP. Enabling UDP in the node configuration doesn’t guarantee the server will accept the forwarded traffic, either. This matters especially for games, voice calls, and some real-time apps. QUIC-based outbound protocols also require UDP connectivity between the client and server. That’s separate from whether the app traffic carried inside the proxy uses UDP.
| Layer | What to check | Common misconception |
|---|---|---|
| Traffic entry point | System proxy, SOCKS, or TUN | Assuming the node is broken when traffic isn’t being routed through it |
| Proxy protocol | Authentication method and endpoint implementation | Judging speed by the protocol name alone |
| Transport and security | TCP, QUIC, TLS, and extensions | Missing a combination required by the server |
| Running implementation | Kernel and supported fields | Assuming UI support means kernel support |
| Network path | Packet loss, congestion, UDP reachability | Blaming protocol differences for differences in network routes |
Build a decision you can verify and revisit
Use four steps: check the full parameters provided by the server, confirm that the client’s kernel supports them, verify that the traffic entry point and rules work, then compare the same task across options. Record success rate, first-page load, sustained transfer, and recovery after a network switch—not one unusually low latency result. If two nodes use different servers or routes, your results describe those two services, not the protocols as a whole. Document these limitations so you can reuse the same criteria when switching clients.
Shadowsocks vs. VMess: lightweight forwarding and protocol authentication
Shadowsocks is commonly abbreviated as SS. It’s designed to provide encrypted proxy forwarding with a relatively direct connection path. Clients typically handle TCP connections and UDP datagrams separately, without requiring a web transport layer, so configurations are often concise. That simplicity comes from clear protocol boundaries; it doesn’t solve every network problem. Security and availability depend on the encryption method, key management, client implementation, and server configuration—not the SS label alone.
Distinguish traditional AEAD methods from Shadowsocks 2022
Common AEAD methods combine encryption with message authentication, allowing the receiver to detect modified ciphertext. Shadowsocks 2022 is a separate set of protocol methods that requires explicit support; it isn’t another name for older methods. It has different requirements for parameters such as key format, and some deployments have multi-user conventions. Changing the encryption method name in an existing node doesn’t migrate it. The client and server need compatible implementations and credentials.
When troubleshooting an SS node, first check whether cipher is supported, then verify the password or key format, server port, and UDP setting. Some nodes also rely on plugins, which provide transport encapsulation outside the SS core protocol. If a subscription converter drops plugin parameters, the node may appear with the right name and address but fail to connect. Check the original node details rather than repeatedly changing the local listening port.
VMess design and authentication boundaries
VMess comes from the V2Ray ecosystem. Its protocol design includes user authentication and proxy request encapsulation, and it can use different underlying transports. It differs from SS in more than just using a UUID instead of a password. VMess has its own request format, authentication mechanism, and data protection, and the connection may add layers such as TLS or WebSocket. The user ID, protocol settings, and outer transport parameters all need to match; a mismatch at any layer can cause the handshake to fail.
When reading older configurations, you may see alterId or alter-id. These fields relate to legacy compatibility paths. Common VMess AEAD configurations today typically use a value of zero, but that doesn’t mean you should change other parameters supplied by the service provider. Field names also vary across software formats. Interpret older guides in the context of the kernel they describe; don’t paste objects from a different configuration format directly into Clash YAML.
VMess authentication depends on system time. If the device clock is significantly off, authentication may fail even when the address and UUID are correct. Check that automatic time synchronization is working rather than weakening certificate verification. The system clock also affects TLS certificate validity, but that’s a separate point of failure. If logs indicate a time or authentication issue, correct the device clock first and then reconnect.
Compare resource use and suitability
On a stable network, with a mature endpoint implementation and no extra encapsulation, SS typically has a straightforward processing path and is a broadly compatible choice for everyday forwarding. VMess overhead must be evaluated alongside its transport combination: direct transport and connections through WebSocket and TLS differ in handshake count and encapsulation. A test comparing multi-layer VMess with direct SS can’t be reduced to a fixed, inherent speed difference between the protocols.
On mobile, also consider connection count and background behavior. During sustained downloads, encryption can contribute to resource use. For occasional messages, waking the wireless radio, DNS requests, and keeping connections alive may matter more. Choose an SS or VMess combination that the server explicitly supports and the current client can fully parse. If older nodes require a client that’s no longer maintained, consider migrating the server rather than relying indefinitely on outdated software.
Trojan vs. VLESS: authentication and transport security
Trojan and VLESS are often used with TLS, but they aren’t the same protocol under different names. Common Trojan deployments carry proxy requests over a TLS connection and identify users with password-based credentials. VLESS keeps the proxy protocol itself lean and leaves transport protection to an external security layer. When comparing them, distinguish authentication, protection against traffic inspection, and server identity verification. These purposes aren’t all handled by the same field.
Trojan: complete TLS setup, then verify proxy authentication
Standard Trojan connections depend on correct TLS configuration. The server address can be a domain or an IP, but TLS validation checks the identity represented by the certificate. sni is generally used to send the server name and take part in connection handling; entering an arbitrary domain won’t make it match automatically. The server certificate, expected name, port, and password must all be correct. Some deployments use a frontend service to route connections, so the provider must explain any additional requirements.
Trojan can forward UDP, but in common implementations, application datagrams are still carried over the reliable byte stream used by TLS. As a result, an app that appears to use UDP locally may still encounter TCP head-of-line blocking along the remote transport path. To assess its suitability for real-time communication, test actual packet loss and interaction quality instead of checking only the node’s UDP flag. Some extensions may add other transport methods; their behavior shouldn’t be assumed to apply to all Trojan services.
VLESS: a lean protocol doesn’t mean the transport is encrypted
VLESS typically uses a UUID as its identity parameter, but a UUID is an authentication identifier, not an encryption switch that replaces TLS. In classic VLESS configurations, encryption: none means the protocol layer doesn’t provide that data encryption. It doesn’t necessarily mean the entire connection is unprotected; check whether the outer layer actually uses TLS, REALITY, or another supported method. Conversely, a configuration without a security layer isn’t encrypted just because it uses VLESS.
VLESS offers many transport combinations, so check client support for the specific features you need. flow isn’t a free-form performance label; it must match a specific traffic-handling mechanism and endpoint implementation. For example, a Vision-related flow requires the server, kernel, transport, and security layer to meet the relevant requirements. Copying flow from another node can break a connection that would otherwise work.
REALITY isn’t just another spelling for a standard TLS toggle. Its public key, short ID, server name, and related handshake parameters must match the server configuration. Field names may differ between software formats, so consult the documentation for the kernel you’re using. Browser fingerprint parameters affect specific handshake behavior, but won’t fix a wrong port, invalid user ID, or mismatched public key. They aren’t a general-purpose speed boost.
How transport options affect your choice
Transports such as WebSocket and gRPC are often used to fit an existing server architecture. They add requirements for paths, service names, headers, or intermediary layers. Extra encapsulation isn’t always slower: the bottleneck may be the network path rather than the processor. But it increases configuration complexity and gives you more to check when troubleshooting. Unless you have a specific architectural requirement, prefer a combination the provider documents clearly, the client supports natively, and that uses fewer parameters.
Neither protocol’s deployment issues should be addressed by turning off certificate verification. Handle expired certificates, server name mismatches, and incorrect system time separately. Skipping verification changes the security boundary and often hides the real problem. If you need to enter sensitive parameters after importing a node, do so in the local client; don’t share full subscriptions or credentials in public screenshots. When sharing troubleshooting details, include only the protocol type, error category, and field names.
Hysteria2 vs. TUIC: different tradeoffs on QUIC
Hysteria2 and TUIC both use QUIC, but that doesn’t make them interchangeable or let them share authentication parameters. QUIC runs over UDP and provides encrypted transport, reliable streams, and connection management—a different foundation from TCP. Hysteria2 focuses on transport and bandwidth utilization over challenging links. TUIC builds proxy requests and data forwarding on QUIC, with its own authentication and UDP handling. Configuration fields and server settings must be matched separately for each.
What QUIC can and can’t do
QUIC can carry multiple streams over one connection. If one stream loses packets, the others don’t have to wait for the same missing data as they would over a single TCP byte stream. However, congestion control, available bandwidth, and some resources are shared across the connection, so requests don’t operate in complete isolation. QUIC can’t eliminate physical distance, severe congestion, or server limits. If the network blocks UDP outright, a QUIC connection may not be established at all.
Connection migration is one of QUIC’s capabilities. Whether a connection survives a switch between Wi-Fi and cellular also depends on the proxy implementation, server policy, and client lifecycle. Mobile operating systems may suspend an app or reclaim its resources, and the client may choose to rebuild the tunnel. When testing network switching, check whether app requests succeed again and whether recovery is stable. Don’t assume every session will survive just because the protocol has connection IDs.
Hysteria2: match bandwidth settings to the real link
Hysteria2 and the earlier Hysteria version don’t use interchangeable configuration formats. After choosing the hysteria2 type, use its corresponding authentication, TLS, and optional parameters. Obfuscation settings must also match the server; don’t enable them at random to try to get a connection. Standard connections still require correct server identity and certificate validation. Using QUIC doesn’t remove those requirements.
Hysteria2 bandwidth negotiation and congestion control depend on both ends’ configuration. The client may use fields such as up and down to specify bandwidth in each direction, but not all deployments require them to be set manually. Larger values don’t automatically increase available capacity; they can cause queuing, packet loss, and interference with other devices on the network. Read the server’s requirements first. If explicit values are needed, set them conservatively based on sustainable bandwidth—not the advertised Wi-Fi link rate.
TUIC: authentication, congestion control, and datagram modes
Common TUIC configurations include a UUID, password, and TLS-related parameters, and may expose congestion control and UDP forwarding modes. Specific fields depend on the TUIC protocol version and client implementation, so “supports TUIC” still calls for checking the server implementation. You can’t put a Hysteria2 authentication string in the TUIC password field and expect the shared QUIC foundation to make the connection compatible.
Congestion control affects sending pace and how the connection responds to network feedback; it isn’t a universal speed setting. The method used to forward UDP datagrams also affects reliability, latency, and overhead. Reliable carriage can prevent some app datagrams from being lost, but may introduce delays. Unreliable carriage stays closer to datagram semantics but requires the app to handle packet loss. Choose based on the application’s needs instead of setting every option to an aggressive-looking mode.
Check network conditions before comparing protocol performance
Public Wi-Fi, corporate gateways, and mobile networks may handle UDP differently. If TCP-based nodes work but two QUIC-based nodes both fail, check UDP reachability, port policies, and the network path before looking at authentication. A connection that drops only after running for a while may be affected by NAT mappings, idle timeouts, or mobile background restrictions. Establish a baseline on a fixed network, then test under your actual usage conditions to avoid misdiagnosing several changing factors at once.
Hysteria2 and TUIC are worth testing on high-latency, lossy links where UDP is reachable, but that’s not a fixed ranking. More aggressive sending may improve throughput while increasing processing overhead and wireless activity. Record device heat, the experience of other devices on the same network, and connection stability alongside download speed.
Connection speed, resource use, and mobile battery life
Compare protocol performance under conditions that are as consistent as possible. Use the same client and device, the same traffic entry mode, and similar testing times. If server location, egress bandwidth, or destination differs, your results describe the entire service path. Protocol processing does vary, but in typical web browsing, DNS resolution and remote server response may account for more of the wait. Not every delay comes from encryption or handshakes.
Measure short connections, reuse, and sustained transfers separately
A first request may involve a DNS lookup, a TCP or QUIC connection, TLS, and protocol authentication. Later requests may reuse an existing transport connection. Specify whether you’re measuring a cold start or a warmed-up connection. Repeated latency tests can show lower numbers as caches and connections are reused, but real apps may not get the same conditions after sitting idle. For short requests, record whether the first and subsequent loads are both consistent.
Observe large-file transfers over a long enough window; don’t record only the initial burst rate. Also distinguish single-connection from multi-connection downloads. The latter may use more network and processing resources, so it doesn’t prove the protocol is more efficient for a single stream. Retransmissions, congestion feedback, and server rate limits all affect throughput. Speed tests consume bandwidth and change the current load, so avoid running a large transfer automatically every time you switch nodes.
There’s no universal processor or memory ranking across devices
Processor usage depends on hardware acceleration for encryption, how the kernel manages buffers, and the number of concurrent connections. An algorithm that runs efficiently on one processor may perform differently on an older mobile chip or small router. QUIC implementations often handle more transport logic in user space, but that doesn’t prove they always use more resources under every workload. Evaluate actual throughput alongside system scheduling.
Memory use also depends on rule sets, DNS caches, connection tracking, logging level, and the client UI framework. Comparing a client with a large rule set against one with a minimal configuration doesn’t tell you about protocol memory use. If a router is under memory pressure, first check connection count, loaded rules, and logging before switching protocols. A desktop client’s total process usage may include its interface; it isn’t the same as the proxy kernel’s usage alone.
Mobile battery use depends largely on wireless activity and background policies
Frequent wake-ups of the phone’s radio, overly frequent keepalives, repeated transmissions under weak signal, and app activity in the background can all increase battery use. An idle connection and continuous video streaming have very different power profiles, so there’s no reliable universal ranking of protocols by battery consumption. At a minimum, measure screen-on browsing, locked-screen idle, and sustained transfers separately. Keep brightness, signal, network type, and app workload as consistent as possible.
Android battery optimization may suspend a client, causing connections to drop after the screen locks. Removing the relevant restrictions can improve continuous operation, but also allows more background activity. iOS network extensions are managed by the system lifecycle, so desktop background settings don’t apply. If a connection drops, check system settings and client logs instead of immediately increasing keepalive frequency. Even if frequent probes keep the connection alive, they may waste battery to maintain an unnecessary online state.
| Test task | What to observe | Conditions to keep consistent |
|---|---|---|
| First page load | Resolution, connection setup, time to first byte | Cache state and destination page |
| Sustained download | Stable throughput, retransmissions, heat | Connection count and download source |
| Idle with screen locked | Background interruptions, unexpected wake-ups | System policies and signal conditions |
| Network switch | Request recovery and reauthentication | Switching method and app type |
If the proxy shows as connected but webpages still fail, follow the step-by-step checklist from system proxy to DNS to verify the connection path. Don’t start performance comparisons before traffic is being routed correctly. A combination that consistently meets your needs is more valuable than a one-time peak throughput result.
Clash, Meta, and mihomo: kernel families and client roles
The original Clash established a workflow centered on YAML configuration, proxy groups, and rule-based routing. Later, different kernel forks and extensions emerged. Meta usually refers to the Clash.Meta development line, while mihomo is the name used by its continuing project. These aren’t three feature plugins that can be arbitrarily combined. Whether a configuration works depends on the running kernel’s support for node types, rule syntax, and related modules—not whether the filename contains “Clash.”
Similar syntax doesn’t mean identical features
Many common fields have a similar structure across implementations, including proxies, proxy-groups, and rules, which can make basic configurations easier to migrate. But support isn’t guaranteed to match for protocol extensions, DNS behavior, TUN settings, or rule capabilities. The fact that an original Clash kernel can use basic nodes doesn’t mean it can read newer extension nodes. When you see an unknown proxy type, check the supported features first; changing YAML indentation won’t fix it.
When reading references, distinguish historical open-source releases, Premium-related features, and implementations in the Meta line. Older articles may say a feature is supported by “Clash” when it applied only to a specific kernel at the time. Don’t combine those claims into a list of features that every client supports. For TUN, rule providers, scripts, and specific rule formats in particular, check the documentation for the kernel you’re actually using.
The client name isn’t the kernel name
If you’re new to Clash, start with Clash Plus, featured on the downloads page. Choose a client for your operating system, then check its protocol and import support. Clash Verge Rev and FlClash are also UI clients; assess their configuration support based on the kernels they actually bundle. The name Clash Meta for Android reflects its place in the ecosystem, but you should still check the implementation in the version you installed. Similar branding doesn’t guarantee identical support for configuration extensions.
Updating a desktop client’s UI doesn’t necessarily mean its running kernel has changed. Some clients let you manage kernels separately; others bundle one with the installer. Check the About page, runtime logs, or kernel manager to verify what’s running. If there are multiple configuration directories, confirm which file the client reads. Otherwise, changes to a backup file may look like a kernel problem when they have no effect on runtime behavior.
Clash for Windows and ClashX Meta appear in our download listings as archived clients that are no longer maintained. These archives can help you understand older setups and plan a migration, but they shouldn’t be the default choice for new protocol features. End of maintenance doesn’t mean existing connections stop working immediately, but don’t expect future system changes, protocol extensions, or fixes to be supported. Keep the original configuration before migrating, then test a copy with the new client.
Migrate between kernels one module at a time
Start with the minimum configuration: a small set of nodes and one manually selected proxy group. Confirm authentication and transport first, then restore rules, DNS, providers, and TUN. This narrows any failure down to a specific module. If a complex configuration is imported all at once and connectivity fails, node errors, DNS loops, routing conflicts, and broken rule references can all be mixed together, making logs harder to interpret. Validate a basic connection before adding features; it’s usually faster than troubleshooting everything at once.
Service mode and administrator permissions are system integration requirements, not remote protocol properties. A kernel’s TUN support doesn’t mean a process without the required permissions can create a virtual interface or change routes. If you need to route more apps, read our guide to TUN mode and virtual network interfaces. For servers and routers, distinguish a graphical client from a standalone kernel deployment, then review the OpenWrt and bypass-router deployment overview to assess resources and network topology.
Subscription compatibility: links, nodes, and full configurations
A subscription is a way to deliver configuration, not a proxy protocol in its own right. A subscription URL may return a full Clash YAML file, a set of share links, an encoded node list, or a configuration for another app. If a client can download the URL, that only means it received a response; the returned content may still be unusable as a configuration for the current kernel. Identify the content type before importing instead of repeatedly refreshing after seeing a format error.
Single-node shares and full YAML configurations contain different information
Share links such as ss://, vmess://, and trojan:// usually describe a single outbound node, and their encoded fields may depend on ecosystem-specific conventions. They don’t necessarily include proxy groups, routing rules, DNS, or local ports. A full Clash configuration is typically organized around these runtime modules. Saving a node link as .yaml doesn’t turn it into YAML; a file extension can’t change the content format.
Likewise, converting another kernel’s JSON configuration into Clash YAML isn’t as simple as changing braces and indentation. Module boundaries, routing expressions, and DNS semantics may be completely different. A converter can only map what it understands, and can’t guarantee that all behavior will be preserved. After converting settings for REALITY, specific flow control, plugins, or newer protocol parameters, check each field carefully. Having the same number of nodes doesn’t mean the configuration has all the information needed to connect.
A proxy provider isn’t a second top-level configuration
proxy-providers loads a set of nodes from an external source for proxy groups to reference. Provider files usually exist to supply node lists; don’t assume they should also merge ports, DNS, and rules from another complete subscription. If the source actually returns a full configuration, whether its nodes can be extracted depends on the client or kernel’s supported processing. Prepare content in the structure expected by the provider rather than assuming it works like importing a main configuration.
This is a standalone local routing baseline that can be parsed on its own, with no remote nodes. Use it to verify ports, proxy group selection, and rule structure—not to measure proxy performance. After importing real nodes, add their names to the relevant proxy group. If you’re using a full subscription, first check the client’s merge behavior so your local rules aren’t overwritten.
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
- name: Manual Select
type: select
proxies: [DIRECT]
rules:
- MATCH,Manual SelectAfter parsing succeeds, check all references
YAML requires correct indentation, list nesting, and string formatting. Values containing special characters may need quotes. Protocol field types matter, too: don’t treat a boolean and a string as interchangeable. But valid syntax is only the first step. Every node referenced by a proxy group, every group referenced by a rule, and every rule provider name must actually exist. If a subscription update renames a node while a locally configured group still uses the old name, the reference may no longer work.
Clients often preserve local settings through overrides, merges, or scripts. Each mechanism has its own timing and scope, so the final active configuration may differ from the downloaded file. Check the runtime configuration to see how nodes and rules were combined. Searching for a field in the subscription editor doesn’t prove the kernel has read it. If needed, temporarily disable local overrides, test the original subscription on a copy, and restore settings one at a time.
Treat update failures and format incompatibility separately
An HTTP error, a redirect to a login page, an empty response, and a YAML parsing error are different problems. Subscription URLs may contain access credentials, so don’t send them to an untrusted online converter; the service could access your complete node details. Prefer the client’s built-in import tools or a method you control. For a detailed update workflow, see how to troubleshoot subscription update failures and configure automatic updates.
Keep a working copy of your configuration before updating. Afterwards, check node types and proxy groups first, then verify rules and DNS. If the server adds a node type your current kernel doesn’t support, use a compatible subscription format or update to a supported client. Don’t simply delete the field that caused the error. Parsing may then succeed, but removing it can change authentication or transport behavior and cause a harder-to-diagnose connection failure.
Choose a protocol for your use case: keep a baseline and compare
Choose based on the service you have, rather than picking a protocol name first and trying to find parameters for it. Both the server and client must support a protocol; changing type locally won’t upgrade the remote endpoint. If the provider offers one tested combination, first check whether it meets your needs. Only test alternatives when you’ve identified a specific limitation, such as UDP being unreachable, unreliable recovery after switching networks, or insufficient device resources.
Desktop browsing and everyday mobile use
For desktop browsing and office apps, start by checking stability, DNS resolution, and rule matching. Mature, compatible combinations of SS, VMess, Trojan, and VLESS can all be suitable; there’s no need to replace a connection that already works just because another protocol has a newer name. Choose a client from Clash Plus or the platform list on the downloads page, check its architecture and system requirements, then verify that it supports the target node’s full transport setup. For the main setup steps, return to the user guide.
On mobile, also test screen locking, network switching, and background recovery. Test on Wi-Fi first, then switch to cellular. If the issue occurs only after switching, check whether the client re-establishes its connection before changing authentication parameters. If you use TUN, also check VPN permissions and conflicts with other network extensions. A client suspended by the operating system and a proxy server rejecting authentication require completely different fixes.
High-latency links and real-time apps
On high-latency, lossy links, compare Hysteria2 and TUIC with your existing TCP-based options if UDP is reachable. Focus on interaction delays, sustained transfers, and effects on other apps—not just peak download speed. If QUIC-based connections often drop on public networks, it’s more practical to keep a tested TCP-based alternative. Test the backup path in advance instead of importing it for the first time after the primary path fails.
For real-time apps such as voice calls and games, verify that datagram forwarding works end to end and watch for long waits or recurring interruptions. Reliable carriage changes how packet loss appears, but doesn’t necessarily improve real-time performance; some apps would rather drop stale data than wait for a retransmission. Test with the actual app, and check whether the destination service is sensitive to IP address changes so a lost app session isn’t mistaken for a proxy protocol problem.
Routers and low-resource devices
For a router, first assess processor architecture, available memory, expected concurrent connections, and rule set size. On resource-constrained hardware, simplifying rules, reducing unnecessary logging, and avoiding duplicate health checks may help more than switching protocols. Test the cost of different encryption implementations and QUIC handling on the target device. Desktop performance isn’t a reliable predictor for a small router, and the rated speed of a hardware network port isn’t the throughput you’re guaranteed to get through a proxy.
For a bypass-router setup, also verify the gateway, DNS, and return path. Protocol choice won’t matter if a device’s traffic never reaches the proxy. Incorrect DNS settings or a routing loop can also make every node fail at once. Validate a minimal topology with a single device before expanding to the whole network. On a stable system, change the kernel and the protocol at different times so you can identify which layer caused a change.
A complete comparison record
- Record the device, operating system, client, and running kernel. Make sure multiple traffic interception tools aren’t active at the same time.
- Save the original configuration, use a fixed network and task, and verify node authentication, transport, and certificate settings.
- Test first requests, sustained use, recovery after idle, and network switching separately. Don’t mix results from different tasks.
- Change one condition at a time. If a test fails, record the error category, then return to the working baseline and confirm the network still works.
- Choose a combination that reliably meets your needs, keep a tested alternative, and retest after important updates.
The final decision comes down to three things: whether the configuration accurately represents the server’s requirements, whether the device can run it continuously at an acceptable resource cost, and whether the network can carry its transport reliably. Compare user experience only after all three are in place. A protocol name is a starting point for research, not a quality guarantee. Repeatable results on your device and for your use case are the basis for keeping a particular node and client combination.