Clash Protocols and Core Reference

1. Choosing a protocol: understand the layers of a connection

What protocols, transports, and clients each do

Selecting a node in a client means choosing a server location, authentication method, proxy protocol, and underlying transport. Shadowsocks, VMess, and Trojan and VLESS primarily describe how a proxy connection is organized; TCP, UDP, TLS, and WebSocket describe ways of carrying traffic at different layers. Hysteria2 and TUIC use QUIC as their transport. Comparing all these names as if they were the same kind of thing can lead you to mistake protocol differences for network-path differences.

The client is where you configure and control the connection; the core parses the configuration, connects to servers, and applies rules. A node appearing in the interface doesn’t mean the current core supports all of its options. Likewise, a core supporting a protocol doesn’t mean a subscription converter will preserve its fields. Check compatibility layer by layer: server requirements, subscription contents, core capabilities, and client settings. Don’t rely on abbreviations in a node name.

Also distinguish application traffic from the proxy tunnel’s transport. A game sending UDP traffic doesn’t mean every node labeled UDP can carry it correctly. And a browser using HTTPS doesn’t mean the outer proxy connection uses TLS. A connection can have multiple layers of encapsulation, each with its own encryption, congestion control, and timeouts. When troubleshooting, first determine whether the application request failed or the connection between the client and proxy server did.

Check compatibility before comparing performance

Follow this order: confirm which protocols the server supports, check that your client and core support them on your system, then compare results using the same provider, similar locations, and similar times. If the server only offers Trojan, changing the node type to VLESS won’t make it connect. A protocol isn’t a cosmetic option the client can switch on its own; authentication and transport settings must match the server.

Don’t treat “UDP support,” “multiplexing,” and “TUN support” as the same capability. UDP forwarding depends on the protocol and server; multiplexing is a way of organizing connections; TUN is a way to route device traffic into the client. TUN can capture traffic from some apps that don’t use the system proxy, but it can’t add UDP forwarding on the server or fix a wrong password or certificate hostname.

Security and maintenance matter too

Prefer maintained clients and cores, keep certificate verification enabled, and get configurations from trusted sources. Encryption on the proxy connection doesn’t mean applications can safely send sensitive data in plaintext: protection after traffic leaves the proxy server still depends on the application protocol. For accounts, payments, and admin panels, use a valid HTTPS connection; encryption on the outer proxy connection is no substitute for the website’s own security.

Subscription URLs often contain access credentials, and configurations may include passwords, UUIDs, or management API keys. Hide URLs and authentication details in screenshots. When asking for help, share only the protocol, error category, and necessary non-sensitive settings. Don’t upload a full subscription file to a public forum; node names can also reveal provider or personal naming information.

2. Shadowsocks and VMess: two approaches to encrypted proxy connections

Shadowsocks: lightweight design, but settings must match

Shadowsocks, often shortened to SS, began as a relatively lightweight encrypted proxy design. It uses a server address, port, encryption method, and password to establish a proxy connection. Its configurations are often compact, making it a good fit for deployments with a small number of nodes to manage. “Lightweight” describes how the protocol is organized; it doesn’t mean every device or encryption method has the same CPU cost, or that every server supports every optional extension.

When choosing SS, check the encryption method and password first. Modern deployments should use an authenticated encryption method supported by both the server and client. Don’t downgrade to an obsolete method just to accommodate old software. Some newer SS methods have specific requirements for key format, length, and multi-user setups, so an arbitrary text password may not work. If an imported node reports an invalid key length, check the source format before changing the port repeatedly.

Test SS TCP and UDP forwarding separately. If web browsing works, that only confirms that the relevant TCP requests succeeded; voice calls, games, and some DNS requests may still fail. Enabling UDP in the client won’t make up for a server that lacks UDP support, a network path that restricts UDP, or an app that isn’t routed through the local proxy. Check the logs to see whether requests reach the core, then verify the server and transport settings.

Some SS deployments also require a plugin. Plugins change the outer connection and add settings such as a plugin type, path, or TLS parameters, so “supports SS” doesn’t automatically mean “supports this plugin setup.” A subscription converter that keeps only the address and password may produce a node that imports successfully but can’t connect. On mobile, check whether the core includes the required plugin support; don’t assume desktop instructions for external plugins apply.

VMess: check authentication and transport separately

VMess comes from the V2Ray ecosystem and organizes connections around identity authentication and proxy data transfer. Nodes typically use authentication details such as a UUID and may combine them with TCP, WebSocket, or another supported transport. VMess behavior depends on the full set of parameters, not just the protocol label. The same UUID can produce very different results with a different path, Host header, or TLS setting.

Older guides may include legacy authentication methods and fields that aren’t current recommendations. If a subscription includes older settings, check the provider’s requirements and core documentation instead of trying values from snippets you find online. Check the device clock, too: authentication mechanisms may depend on the system time being reasonably accurate. If the clock is noticeably off, enable automatic time sync before concluding that the node is broken.

With WebSocket, check the connection port, request path, Host header, and TLS server name separately. Host is an HTTP-layer value; the server name is used for the TLS connection and certificate verification. They may be related, but they aren’t always interchangeable. For reverse-proxy deployments, the path must match the server’s forwarding rules. A wrong path may show up in the logs as an HTTP response error rather than an authentication failure.

How to make a meaningful comparison

SS settings are relatively compact, which suits deployments that need fewer outer-layer options. VMess offers more combinations, which can make it easier to integrate with existing transport infrastructure, but also adds troubleshooting steps. This doesn’t mean SS always uses less battery or VMess is always slower. Encryption implementations, CPU instruction support, network latency, and connection reuse all affect results. An older router may also behave very differently from a modern phone.

When comparing, keep the exit region, server resources, and target file as similar as possible. If two nodes use different machines, your results mostly reflect the overall quality of those nodes. For everyday use, more useful measures include how quickly pages open, how stable long transfers are, how quickly connections resume after idle periods, and whether they recover when you change networks. A single connection-time test is only one clue.

3. Trojan and VLESS: combining TLS, authentication, and transport

Trojan: check all TLS requirements

Trojan carries proxy authentication and data over a TLS connection; common deployments use password authentication. It uses established TLS transport for protection, then carries proxy requests within it. For client users, the main settings to check are the node address, port, password, and server name. A trusted certificate chain and accurate system clock matter too, so don’t focus only on the password field.

Certificate verification checks the server’s identity, not just whether “encryption is enabled.” The connection address can be an IP or domain, but the certificate must match the name being verified. Some deployments require a separate server name; enter the value provided by the service, not the node’s display name. Expired certificates, hostname mismatches, and incomplete certificate chains should be fixed by the configuration provider or server administrator.

Skipping certificate verification weakens authentication and shouldn’t be a routine fix. If only one device reports a certificate error, check its clock, system trust store, network intermediaries, and client logs. If all devices fail at once, look at the server certificate and deployment changes. Changing the verification setting may silence the error, but it doesn’t prove you connected to the intended server.

Trojan’s UDP support isn’t necessarily the same as native UDP transport. Common implementations encapsulate UDP data in a reliable connection, with the exact path depending on the core and configuration. This can provide the forwarding behavior an application needs, but packet loss may cause delays while the outer reliable transport waits. Test voice and game performance in the actual app rather than relying on a UDP support label.

VLESS: lightweight authentication doesn’t provide encryption on its own

VLESS is designed to separate authentication from outer-layer transport protection; the protocol itself doesn’t encrypt content. Deployments commonly pair it with supported secure transports such as TLS or REALITY, so a VLESS node isn’t just a UUID to fill in. The client must support the server’s security layer, transport, and any required flow-control mode. Missing any part of the combination can prevent a connection.

REALITY, Vision, and VLESS aren’t interchangeable protocol names. VLESS is a proxy protocol, REALITY is a security transport, and Vision is a specific flow-control mode. Subscription fields such as the public key, short ID, server name, and flow control each serve a purpose; don’t assume a field can be removed just because the interface doesn’t display it. Basic VLESS support doesn’t guarantee that a client supports every extension.

VLESS over WebSocket still requires checking the path, Host header, and TLS settings. With a specific flow-control mode, confirm that the server and client support the required transport combination. Don’t copy flow-control fields from one deployment into another. When migrating, keep the original combination intact, verify the connection, and only then consider changes. Changing the protocol, transport, and DNS all at once makes problems harder to isolate.

Measure differences even when the security layer is the same

Trojan and VLESS can both use TLS, so part of their handshake and certificate-processing cost is shared. Their authentication, encapsulation, and extension support differ, though, so don’t attribute every performance difference to TLS. First-byte latency also includes DNS resolution, TCP connection setup, the security handshake, and the target server’s response. A single lightweight test endpoint can’t represent how a webpage with many resources will load.

If your provider offers both types of node, start with the configuration that has complete fields and is clearly supported by your current core, then test it with your everyday apps. When you need multiple transports to work with existing server infrastructure, checking compatibility matters more than comparing protocol names. If you just want to keep using a working subscription, there’s no need to rebuild nodes by hand to change their labels. Server maintenance, certificate renewal, and timely configuration updates all affect long-term reliability.

4. Hysteria2 and TUIC: what QUIC connections can and can’t do

Which layer does QUIC change?

QUIC runs over UDP and integrates secure handshakes, reliable streams, and connection management. Hysteria2 and TUIC use these capabilities to carry proxy traffic, aiming to reduce some connection overhead, improve concurrent transfers, and adapt to challenging network paths. But UDP is only the transport foundation; it doesn’t guarantee a better route. If your network throttles or drops UDP, or enforces short timeouts, QUIC-based nodes may be less stable than TCP-based ones.

QUIC’s multiple reliable streams can reduce waiting between streams caused by in-order delivery at the transport layer. Lost data within a stream still needs to be handled, though, and all streams may share a congestion window and underlying link. QUIC can’t prevent weak wireless signals or exceed server bandwidth. It may help when a webpage loads many resources concurrently, while a single file download still depends mainly on available capacity, packet loss, and congestion control.

Connection identifiers provide a mechanism for handling network path changes, but seamless recovery when switching mobile networks also depends on the protocol implementation, server state, NAT, and client behavior. QUIC doesn’t guarantee a connection will never drop. When a phone switches from Wi-Fi to cellular, check whether the app recovers, whether the core performs a new handshake, and whether the OS allows it to keep running in the background.

Hysteria2: bandwidth settings aren’t a speed multiplier

Hysteria2 focuses on configurable transport strategies for less-than-ideal network paths. Common configurations include authentication, TLS, and optional bandwidth declarations; congestion control depends on the settings at both ends. Upload and download declarations describe link conditions, not a “higher is better” target. Setting an unrealistically high capacity for a limited uplink can cause queue buildup, retransmissions, and slower responses from other apps, making the overall experience worse.

When checking bandwidth settings, first confirm the direction and units, then estimate the capacity actually available. A home internet plan’s advertised speed isn’t the same as the sustained bandwidth available on the proxy route, and cellular capacity varies with signal and congestion. If you can’t estimate it reliably, keep the settings from a trusted configuration source and use the core’s defaults. Don’t copy inflated numbers from the internet. After adjustments, check throughput, responsiveness, and packet loss.

Hysteria2 isn’t simply a renamed, compatible version of the earlier Hysteria configuration. If a subscription converter mixes up the protocol type, authentication fields, or obfuscation settings, it may generate a node that imports but won’t connect. Optional features such as obfuscation and port hopping also require support from both the core and server. Start troubleshooting with the provider’s complete configuration, confirm the basic connection, and then check these extensions one by one.

TUIC: concurrency and UDP forwarding need support at both ends

TUIC also uses QUIC to establish connections and includes mechanisms for authentication, stream forwarding, and UDP forwarding. Different implementations or configuration versions may require different authentication fields and parameters, so a TUIC label alone doesn’t confirm compatibility. Check that your current core explicitly supports the provider’s configuration format. For unknown fields, start with the core logs and the subscription’s target format instead of deleting them outright.

TUIC options for congestion control, UDP forwarding, and keepalives affect runtime behavior. Reliable forwarding prioritizes delivery; unreliable datagrams are better suited to applications that can tolerate packet loss but need timely data. The result still depends on the implementations at both ends, so option names don’t prove that every game will benefit. For real-time apps, test an actual call or game session and watch for jitter, interruptions, and recovery time.

For both QUIC node types, check MTU, UDP availability along the network path, and router behavior. If small requests work but larger transfers stall, fragmentation or packet size may be involved—but don’t assume every timeout is an MTU issue. Try another network and see whether only QUIC nodes fail, then adjust settings according to the client documentation. Keep a working TCP-based node as a comparison so you don’t lose a useful baseline.

5. Connection speed, resource use, and mobile battery life

Measure initial connection and sustained transfers separately

“Fast” can mean quick first response, high sustained throughput, low interaction latency, or fast recovery after a disconnect. First response depends on DNS, connection setup, the security handshake, and target server processing. Sustained throughput depends on capacity, packet loss, congestion control, and server load. A node that opens pages quickly may not suit long downloads; one with high download throughput may still jitter during a video call.

A client’s connection test usually probes a specific target and only describes that test route. Different targets or connection-reuse behavior make the results unsuitable for direct comparison. An automatic selection policy may also switch nodes frequently as probe results fluctuate, disrupting long-lived connections. Understand how the test works before enabling automatic selection. For stable sessions, pinning a suitable node often makes troubleshooting easier.

For a fair comparison, keep the device, network, target resource, and rules the same; pause bandwidth-heavy background tasks and change one variable at a time. Test a page’s cold start, then a sustained transfer, then recovery after idle. Alternate between options over multiple rounds so peak-hour changes aren’t mistaken for protocol effects. If nodes use different exits or servers, report the results as node performance—not proof that one protocol is faster overall.

Where CPU and memory are used

CPU overhead comes from encryption and decryption, encapsulation, data copying, rule matching, and protocol-stack processing. Hardware acceleration on modern devices can make some encryption methods inexpensive, while older routers may be limited by single-core performance. QUIC’s user-space processing, frequent small packets, and high concurrency can also add overhead. If throughput is low, check processor load as well as network conditions instead of just switching nodes again.

Memory use depends on connection count, buffers, rule sets, DNS cache, and the client interface. Monitor the interface and core processes separately, and restore normal logging levels; verbose logging can add overhead when left on. Connection reuse can reduce repeated handshakes but requires extra state. More concurrent connections or larger buffers don’t always help, especially on low-memory routers and phones with restricted background activity.

TUN adds local traffic capture and processing steps; DNS interception, process detection, and rule matching can also change overhead. That means system proxy and TUN results aren’t a direct comparison of protocols. If an app uses different rules under each method, its actual exit route may differ too. Before comparing, use connection logs to confirm that the same app and destination use the same node and policy.

Battery life depends on wakeups, signal strength, and actual traffic

Mobile battery drain doesn’t come from encryption alone. Cellular radio activity, retransmissions under weak signal, background keepalives, and frequent app requests can have a major impact. Keeping a protocol connection alive longer may reduce handshakes but also keep the radio active longer. Shorter timeouts may reduce idle use but force later requests to rebuild connections. There’s no universal battery-efficiency ranking that applies to every phone.

For a battery comparison, keep screen brightness, signal conditions, apps, and test duration consistent, then measure idle and active use separately. OS battery stats depend on how usage is attributed: traffic through a VPN interface may be counted under the client, even though that doesn’t mean all the energy was spent on proxy processing. Consider total battery drain, data use, and background activity rather than judging by the client’s position in the battery list.

For everyday optimization, cut unnecessary frequent checks and verbose logs, keep subscription updates at a reasonable interval, and look for apps that repeatedly retry failed requests. Overly strict battery restrictions can kill background connections, so balance battery life against continuous connectivity. On Android, check background-running permissions; on iOS, check VPN status and on-demand connection settings. Switching protocols alone can’t fix these operating-system behaviors.

6. Upstream Clash, Clash Meta, and mihomo: how cores and clients fit together

Related names don’t mean identical capabilities

Clash originally referred to a proxy core project and later became a broader label for related configurations and clients. The original open-source core, the historical Premium branch, and the later Meta line don’t share a single feature set. Older guides that say only “Clash supports this” may leave out which branch they mean. For rule types, TUN, and protocol extensions, look for the exact core name instead of relying on the interface title.

Clash Meta extended protocols and features in the existing ecosystem, and mihomo continues along that line. Many clients and subscriptions still use the Meta name, so a different name doesn’t necessarily mean a different configuration system. But a continued lineage doesn’t guarantee every build supports every new field. Check the core that’s actually running and its documentation; don’t assume an older installer supports features described in current docs.

Premium once included capabilities that differed from those in the open-source original. Don’t assume its proprietary settings or scripting features can be migrated to mihomo. Some fields may serve similar purposes but use different implementations or syntax; keeping them unchanged can cause parsing errors or change behavior. When migrating an old configuration, first build a minimal working setup, then restore rule sets, DNS, TUN, and automation one at a time.

The client provides the interface; the core does the work

The client handles subscription management, node selection, system proxy settings, and log display. It may also provide configuration overrides and core updates. Interface settings often generate or modify the runtime configuration, so the original subscription file on disk may differ from what the core actually loads. Check the client’s runtime or merged configuration when troubleshooting, especially for DNS, ports, proxy groups, and TUN settings that may be overridden by the interface.

For a first client, start with Clash Plus for your platform, then compare Clash Verge Rev, FlClash, and others if needed. On Windows, you can also consider Clash Nyanpasu; on Linux, compare Clash Verge Rev and FlClash. A recommended client isn’t implemented identically on every platform. If you need a protocol extension, check the capabilities and parameter support of the build for your platform.

On Android, evaluate Clash Meta for Android and Surfboard on their own merits. Surfboard has its own configuration system; being a proxy client doesn’t mean it can use Clash YAML directly. For iOS, see the App Store link for Clash Plus and its official site, clashplus.io, on the download page. When moving between operating systems, compare the specific configuration and capabilities, not just app names.

Archived apps, core updates, and migration limits

Clash for Windows and ClashX Meta are marked as discontinued in this site’s download list and may suit users with specific compatibility needs. Archived clients may lack support for newer protocol fields, OS changes, and security fixes, so don’t choose one for a new install just because you recognize its screenshots from older guides. Read the archived clients guide to decide whether to keep an old setup or migrate.

Updating the client and updating the core may be separate steps, or the client may manage both. Before an update, save your local rules, overrides, proxy group names, and system traffic settings. Afterward, verify subscription parsing, rule matches, DNS, and everyday apps. Don’t change the client, subscription format, and every node at once; if something breaks, it’ll be hard to identify which layer changed.

Running mihomo directly suits users managing servers, routers, or their own services, but also means handling process permissions, startup, logs, and configuration paths. Most desktop users will find a GUI more convenient. Running the core directly doesn’t automatically provide transparent proxying or replace routing, DNS, and firewall design. Before deployment, decide which devices’ traffic needs to pass through the core.

7. Subscription formats, YAML configurations, and migration compatibility

Share links, node lists, and full configurations are different

A subscription is a way to retrieve configuration, not a single standardized file format. A URL may return a collection of encoded share links, a complete Clash YAML file, or a configuration for another client. Share links typically describe individual nodes; a full configuration may also include proxy groups, rules, DNS, and listening ports. Seeing nodes after import doesn’t mean the original routing logic was preserved—check the proxy groups and rules too.

Choose a subscription output format that matches the client you actually use. Traditional Clash formats, formats that include mihomo extensions, and formats for other apps aren’t interchangeable by default. Converters handle common fields, but may drop newer protocol extensions, custom transports, and plugin settings. After conversion, check node types and key parameters. “Conversion successful” doesn’t verify the whole connection.

The subscription response may also change based on the request method, account status, or provider settings. If an update suddenly returns no nodes, check whether you received a webpage, sign-in prompt, or error message before assuming the YAML is invalid. Don’t delete the original configuration; a working copy helps you compare changes. When sharing troubleshooting details, remove credentials and provide only the structure and error. Never post the original subscription URL publicly.

Configuration layers determine overrides and update behavior

In Clash-style configurations, nodes, proxy collections, proxy groups, and rules each have a different role. A proxy collection can load nodes from another source, a proxy group selects an exit, and rules assign requests to policies in order. Referenced group names must exist; changing a name can prevent startup or alter routing. A subscription update that adds nodes won’t necessarily add them to a manually defined proxy group.

Client overrides usually preserve local preferences so you don’t have to redo settings after every subscription update. But merge behavior may replace, append, or merge by name, and clients don’t all behave the same way. Check where appended rules go: entries placed after the final catch-all rule usually won’t take effect. Read the override documentation, then inspect the actual runtime configuration to confirm the result.

Use the following rule snippet in the appropriate configuration section. The example’s PROXY must match an existing proxy group. Domain rules come first, followed by LAN and region rules; the final catch-all handles connections that haven’t matched. This shows rule order only—it doesn’t include nodes or a complete DNS setup. Region rules also need the relevant data, and you should verify actual matches using DNS results and connection logs.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Validate syntax first, then behavior

YAML requires correct indentation and data types; use spaces for indentation. Quote passwords, special characters, and values that might be misinterpreted as required by the source format. Don’t replace English punctuation with full-width punctuation when copying. For parsing errors, check indentation, list markers, and key-value relationships near the reported line. For unknown fields or unsupported types, check core capabilities instead of assuming every error is a formatting issue.

Validate a migration in three stages: confirm the configuration loads, test access through one known node, and then restore automatic policies and complex rules. If the basic node works but domains fail, check DNS. If an individual node works but an automatic group doesn’t, check its members and health-check conditions. If the system proxy works but TUN doesn’t, check local traffic capture and permissions. This order reduces cross-layer interference.

Set the subscription update interval to match how often the provider changes its configuration. Updating too often may trigger source-side limits and increase background activity on mobile. Going too long without an update can leave you with dead nodes or outdated certificate settings. If an update fails, check the URL and account status first, then the network and response content. Rule data and node subscriptions may come from separate sources, so check their update times and load logs separately.

8. Choose by use case and follow a troubleshooting sequence

Where to start for desktop work and mobile use

For desktop work, make sure browsers, development tools, and meeting apps have a clear connection path. Import a full subscription into a suitable client such as Clash Plus, then check that common destinations match the expected rules in rule mode. If an app supports an explicit proxy, start by testing with the system proxy or the app’s own proxy settings. Consider TUN only when you need to capture more apps, so you don’t introduce permission, routing, and protocol issues all at once.

For everyday phone use, prioritize recovery and background reliability over peak download speed. Keep the trusted configuration’s default transport settings and test Wi-Fi and cellular separately. If a QUIC node only fails on one network, keep a TCP-based node as a backup. Under a weak signal, improve reception or switch networks first; increasing the bandwidth declaration usually won’t fix retransmissions or radio battery drain.

For voice calls and games, confirm that the app’s UDP traffic reaches the core, then check forwarding support on the node and server. Focus on jitter, packet loss, and session stability; a large-file speed test isn’t a substitute. Some games also rely on local discovery, specific ports, or region-based service policies. A proxy only handles connections within its scope, so one successful webpage doesn’t prove the entire game network is configured correctly.

Routers, side routers, and high concurrency

When running mihomo on a router, check the hardware architecture, available memory, and CPU capacity before choosing protocols and rule-set size. Complex transport combinations, high concurrency, and large rule data can increase resource use. If every device on the network slows down at once, check router load and connection status before assuming all your nodes have become worse.

A side router also requires clear gateway, DNS, and return-path settings. If one device can connect and another can’t, the difference may be how traffic is routed—not protocol compatibility. Don’t start by changing protocols on every device. Check the default gateway, DNS path, and routing rules, then test the same destination. See Running mihomo on a router or side router for deployment details, alongside this guide’s protocol advice.

Narrow down the cause by failure stage

First, check that the configuration loads. If the core won’t start or nodes don’t appear, look at YAML, subscription format, unknown protocols, and field support. Next, check the connection to the server: DNS errors point to name resolution, connection refusals to the address or port, and timeouts call for comparison across networks and transports. Then check the security handshake and authentication: verify the certificate name, system time, password, UUID, and extension parameters against the source.

Next, check access to the destination. If the connection to the server succeeds but the request still fails, check which policy the rules selected, how the destination domain resolved, and whether only a particular request type is affected. If a webpage works but an app doesn’t, check how the app connects to the client. If a domain fails but its IP address works, focus on DNS. Don’t hide the root cause by permanently disabling certificate verification, adding arbitrary direct rules, or deleting fields that trigger errors.

Only then tune performance. First try another node under the same conditions, then a different transport, and finally adjust bandwidth declarations, multiplexing, or TUN settings one at a time. Record each change and result, and keep a way to revert. When reporting an issue, include the OS, client, core name, failure stage, and redacted logs. Don’t attach an original subscription, password, or complete configuration publicly.

Choose a setup you can explain, recover, and use reliably—not one with the most settings. For speed issues, follow the three-layer method for checking nodes, network paths, and local settings. For installation and permissions, return to the quick-start guide; for individual errors, see the FAQ. Avoid changing settings across unrelated layers without a clear reason.