Clash Protocol and Core Guide

Four layers to consider when choosing a protocol

Client, core, protocol, and network path

Names in the Clash ecosystem refer to different layers. The client handles the interface, subscription management, system proxy, and permission requests. The core establishes connections, applies rules, and handles DNS. The protocol defines how the client and server authenticate, encapsulate, and transport data. The network path determines which networks that data actually crosses. Choosing a client does not determine the protocol. Even after installing a GUI that supports mihomo, you still need to confirm the node types and server parameters in your subscription.

Problems can occur at any of these four layers. A configuration importing successfully only means the file reached the manager; it does not guarantee the core recognizes every field. A node showing as connected only confirms that a connectivity check completed; it does not mean it is suitable for video, downloads, or real-time calls. Two nodes using the same protocol may still have different servers, egress routes, transport layers, and bandwidth policies. When comparing protocols, keep the server location, test destination, and test time as consistent as possible. Otherwise, you may be measuring differences in the network path instead.

Start with your constraints, not a ranking

First, list your device's operating system, client core, server-side protocol, and the transport options available on your current network. An office network might allow TCP but restrict UDP. A mobile network can change your IP address when you switch cell towers. Older devices may lack efficient hardware for cryptographic operations. If the server offers only one protocol, changing a type field in the client will not turn it into another. Both ends must use matching protocols, ports, credentials, and transport options.

Next, identify what you mainly use the connection for. Web browsing is more sensitive to first-response time and the cost of short-lived connections. Large file transfers depend more on sustained throughput. Voice calls and games are more sensitive to jitter, packet loss, and UDP forwarding. Remote desktop needs both low interaction latency and reliable reconnection. A setup that performs well during a long download may be a poor fit for calls on a weak network. Optimizing for one test can also increase background traffic and battery drain.

Evaluate security and connection quality separately

Encryption and authentication determine whether the connection endpoint is trusted and how data in transit is protected. Speed tests measure the service provided by the current path. Neither is a substitute for the other. For certificate-based configurations, verify the certificate chain and server name. For pre-shared credentials, make sure they come from a trusted source. Don't disable authentication checks indefinitely just because a node tests faster, or assume a newer protocol name means stronger security.

This guide does not rank protocols by speed. Protocol overhead depends on the processor, cryptographic implementation, path MTU, packet loss, and server load. As you read the sections below, record three things for each candidate node: whether your current core fully supports it, whether your network allows its underlying transport, and whether it improves your actual workload. If any point is uncertain, keep the configuration you have already verified. There's no need to change several settings at once.

SS and VMess: Design Trade-offs in Encrypted Proxies

Shadowsocks: a lightweight proxy design

Shadowsocks, usually shortened to SS, uses a relatively simple proxy model. The client accepts a local connection, wraps the destination address and application data, and sends them to the server, which then connects to the destination. Deployments don't all require web-based transport or certificates. A basic configuration mainly needs a server, port, encryption method, and credentials. This makes cross-platform implementations straightforward and gives troubleshooting fewer required fields to start with, but it doesn't mean all SS nodes behave the same way.

SS encryption methods are not interchangeable. Older stream ciphers, common AEAD methods, and later Shadowsocks 2022 methods use different key formats and implementation requirements. The client must support the method configured on the server. Some methods require a key of a specific length and encoding, not an arbitrary password. If importing fails, check the method name and key format first rather than changing the server port at random.

SS can carry TCP traffic and can also forward UDP when both endpoints and the network support it. The UDP toggle in a client only expresses local intent; the server, subscription, and network path must also support UDP. If web pages work but games or calls don't, check whether that traffic is actually routed through the proxy, whether the server supports it, and whether the network restricts UDP. A single web connectivity check cannot confirm that UDP forwarding works.

VMess authentication and transport combinations

VMess comes from the V2Ray ecosystem. It uses a user identifier for authentication and has its own encryption and encapsulation mechanisms. A node may combine it with transports such as TCP or WebSocket, and may also use TLS. Describe the full combination when comparing performance; saying only that VMess is faster than another protocol is not meaningful. Direct connections and connections routed through an additional gateway can differ significantly in handshake count, encapsulation overhead, and support from intermediary devices.

Time synchronization is worth checking when troubleshooting VMess. Its authentication mechanism has requirements related to the device clock, so an incorrect system time can cause authentication failures that the interface may show simply as a timeout or closed connection. Enable automatic time synchronization in the operating system first, then check the user ID and server logs. Older subscriptions may also include legacy compatibility parameters whose meaning depends on the core implementation. Don't blindly reuse values from outdated tutorials.

A WebSocket path, request hostname, and TLS server name are different things. The path is part of the application-layer handshake, the request hostname is used for HTTP routing, and the TLS name is used during the handshake and certificate verification. These values may be the same, but there is no general rule that they must be. If a server sits behind a reverse proxy, a missing path or incorrect request header can let the connection reach the server without establishing a proxy session. That's not a routing-rule problem.

Practical limits for selection and maintenance

On a verified TCP network or a resource-constrained device, a relatively simple SS configuration can make a useful baseline. If you already have a complete VMess deployment, there's no need to migrate immediately just because its name seems dated. Evaluate the server's maintenance, encryption settings, client support, and performance on your everyday tasks. Additional transport encapsulation may meet specific deployment needs, but it adds fields that must match on both ends and does not automatically improve speed.

If an SS configuration includes plugin parameters, check that the client implements the plugin and the specific mode in use. Basic SS support does not imply support for every plugin, and conversion tools may drop plugin options. VMess also has compatibility limits for its transport combinations. Keep the original link and configuration source, then compare converted fields one by one. That's more effective than repeatedly switching modes. For import issues, see the installation and configuration notes in Frequently Asked Questions.

Trojan and VLESS: Authentication, TLS, and Transport

Trojan: TLS as the secure transport layer

Common Trojan deployments use TLS as an outer secure channel, with proxy authentication and data forwarding inside it. They don't require users to maintain a separate list of application-level encryption algorithms. Instead, the key settings are the password, certificate, server name, and server listener. This is a division of responsibilities: TLS protects the transport, while the proxy protocol handles destinations and authentication. A deployment is only reliable if certificate verification and server settings are correct.

The connection address and certificate name can differ. For example, a client can connect to one address while the server certificate is issued for a domain. In that case, set the correct TLS server name and make sure the certificate matches it. SNI is the mechanism that sends the server name during the handshake. Certificate verification checks identity and the trust chain. They are related, but not the same thing. Entering a plausible-looking domain doesn't make an invalid certificate trustworthy.

When troubleshooting a failed Trojan connection, distinguish between a TCP connection failure, a failed TLS handshake, and failed proxy authentication. The first usually involves the address, port, or network path. For TLS, check the device clock, certificate validity, name match, and trust chain. Check the password and server authentication settings only if proxy authentication is the failing stage. Clients may show several types of failure as a timeout, so use the logs to identify where it failed instead of changing every TLS option.

VLESS: a lightweight protocol is not a standalone encryption layer

VLESS also comes from the V2Ray ecosystem. Its design reduces some of the protocol's own overhead and relies on the chosen transport security mechanism for protection. Don't assume that entering a user ID alone provides complete encryption. Common configurations use TLS or REALITY, but support depends on the client core and transport combination. If security-layer fields are missing from a subscription, ask the configuration provider rather than guessing at defaults.

REALITY configuration differs from conventional certificate-based TLS and typically involves matching parameters such as a public key, short ID, and server name. A correct user ID won't prevent connection failures if those fields don't match. Some VLESS deployments also specify a flow-control mode, such as a particular Vision flow required by the server. This is a constraint on implementation and negotiation, not a universal speed boost. Keep the setting required by the server; don't copy it to every node just because you see it in one configuration.

VLESS nodes can also use different transports. A client that supports the base VLESS protocol may not support every transport, security layer, and flow-control combination used by a server. Share links may not encode every extended field either. To confirm compatibility, check the combination limits in the documentation for your current core and verify the generated configuration. A client name or a simple protocol support list cannot cover every compatibility detail.

Certificate verification and connection reuse

Disabling certificate verification weakens the client's ability to confirm the server's identity and should not be used as a permanent fix. For self-signed certificates, configure a trusted certificate or an appropriate identity constraint if the client supports it. With public certificates, fix the name or certificate chain instead. If only one device fails, check its system clock, trust store, and whether security software is interfering with the connection. Different results on the same node can come from the local environment, not the protocol.

Connection reuse lets multiple logical requests share an underlying connection, reducing repeated setup costs, but it can change how congestion is shared and how widely a failure affects requests. If the shared connection stalls, several requests may be affected at once. If the server doesn't support the reuse method, you may see seemingly random interruptions. When choosing Trojan or VLESS, first verify the smallest configuration explicitly supported by the server. Then evaluate reuse, transport encapsulation, and flow control. This makes problems easier to isolate than enabling everything at the outset.

Hysteria2 and TUIC: QUIC-Based Connection Models

What QUIC changes

QUIC typically runs over UDP and combines an encrypted handshake with reliable transport and multiple streams. UDP is the underlying transport; it doesn't mean application data is necessarily unreliable. Web pages and files can still be delivered over reliable streams. Compared with multiple logical streams sharing one TCP byte stream, QUIC can reduce head-of-line blocking between streams. However, streams on a shared connection still contend for the same path, congestion capacity, and available bandwidth. QUIC cannot exceed the physical network's capacity.

Hysteria2 and TUIC both use QUIC, but they are distinct protocols, not different names for the same thing, and their authentication fields are not interchangeable. If the server listens for Hysteria2, the client must establish a Hysteria2 session. Different TUIC protocol generations also require matching support. A client interface saying it supports QUIC does not prove that it can connect to every QUIC-based proxy service. Check the node type and implementation details.

Hysteria2 bandwidth estimates and congestion trade-offs

Hysteria2 is designed for transport over lossy and challenging network paths, with congestion-control choices related to bandwidth settings. The upload and download values in a configuration generally describe expected client-side capacity; they shouldn't simply copy the server's advertised network speed. Overestimating available bandwidth can increase queues, contention, and packet loss, affecting web responsiveness and other devices on the network. Underestimating it can constrain sustained transfers.

The server can also limit bandwidth or affect negotiation, so the value entered on the client alone doesn't determine the final behavior. Start with the configuration recommended by the operator, then evaluate sustained downloads alongside interactive tasks. Some optional obfuscation settings must match on both ends; they don't replace certificate verification or authentication. If the handshake stops working after a change, revert those options first rather than assuming bandwidth is the problem.

TUIC streams, datagrams, and connection maintenance

TUIC also uses QUIC to carry proxy sessions. Its configuration may include a user ID, password, congestion control, UDP forwarding mode, and connection maintenance parameters. TCP proxy streams and UDP traffic are handled differently. When choosing reliable forwarding or datagrams, consider whether the application prioritizes timeliness or completeness. Real-time calls usually care about promptly dropping stale data, while file transfers require reliable, ordered delivery. The vague label “stable” doesn't capture both needs.

Keepalive and idle timeout settings determine how a connection behaves when there's no traffic. Address-translation devices on mobile networks may reclaim UDP mappings quickly, so an appropriate keepalive can help subsequent data get through. But overly frequent keepalives increase wireless wake-ups and background traffic. Whether a connection survives a network change also depends on the implementation, server, and network path. QUIC connection migration does not guarantee that every client will preserve a session.

UDP paths are not always available

If your current network significantly restricts UDP, these protocols may have more trouble connecting than TCP-based options. Increasing the number of retries usually won't fix an unreachable underlying path. Also consider packet size after encapsulation: additional proxy layers, tunnels, or access networks can reduce the path's usable MTU, causing small requests to work while larger transfers stall. Use logs and a comparison network to check each layer. Don't change system-wide parameters on every device without a clear reason.

A useful test is to keep a verified TCP configuration as a baseline, then test web browsing, sustained transfers, and recovery after idle periods on the same network. QUIC may work better on some lossy paths, but it may also be rate-limited by the network operator. Choose based on repeatable improvements for your actual workload, not a single peak-speed result. Any subsequent tuning should also account for server capacity and other applications sharing the network.

Speed, Resource Use, and Mobile Battery Life

Break speed tests into stages

The wait you experience includes DNS lookup, the underlying connection, the protocol handshake, the destination site's response, and content transfer. A node latency check usually covers only part of that process; it doesn't predict the first visible content on every website. A node can respond quickly to a probe but download slowly because of a poor route to the destination. To compare protocols, record first visits, repeat visits, and long-lived connections separately. This helps avoid mistaking caching or connection reuse for a protocol advantage.

Sustained throughput depends on the send window, congestion control, round-trip time, and packet loss. On a high-bandwidth path with a long round-trip time, enough data must be in flight to use the available capacity. After packet loss, different control strategies also recover at different rates. But sending more aggressively isn't always better: it can fill queues on the access link and increase interactive latency. When testing download speed, also open a frequently used website or make a voice call to see whether performance comes at the expense of other traffic.

CPU overhead comes from the entire processing pipeline

Encryption is only one part of resource use. User-space networking, data copies, transport encapsulation, connection reuse, rule matching, and logging all consume CPU time. Processors also differ in hardware support for specific cryptographic algorithms, so desktop results don't necessarily apply to phones or routers. If a low-power device stays under heavy load, compare system proxy and TUN modes, as well as minimal and full configurations, to identify the bottleneck.

Memory use is also affected by the number of connections, rule sets, subscription size, caches, and interface processes. Comparing the total memory use of two clients doesn't necessarily reveal a difference in core efficiency: one may load more rules, while the other may have its connections panel closed. Keep rules and workloads consistent, and monitor the GUI and core processes separately. Memory headroom is especially important on routers, where an out-of-memory process exit can look like a dropped connection.

Mobile battery use and wireless wake-ups

A phone's battery is used not only for encryption, but also for keeping wireless connections alive, waking in the background, reconnecting, and probing traffic. Checking every node frequently, using overly short keepalive intervals, and continuously writing detailed logs can all prevent the device from staying idle. A protocol name alone cannot tell you which option will use the least power. Compare on the same phone, network, and approximate workload, keeping screen brightness and signal strength as consistent as possible.

Mobile operating systems typically route traffic through a VPN or network extension, depending on the platform and client. A TUN label in the client doesn't necessarily mean it uses the same implementation as a desktop client. Power-saving policies may suspend background activity, requiring sessions to reconnect when the app resumes. If the connection fails after the screen locks but works in the foreground, check background permissions and network recovery before changing protocols. Shortening the keepalive interval blindly may hide the issue while increasing everyday battery use.

Keep comparisons reproducible

Change one factor at a time. Keep the node region and destination consistent, fix whether TUN is enabled, disable automatic node checks, and test short requests, large transfers, and recovery after idle periods separately. Don't update subscriptions, switch DNS, and change congestion settings during the same download; you won't be able to explain the result. Record when the issue occurred, the network type, the failure stage, and the task's behavior—not just a screenshot of a peak-speed result.

If only a specific app is affected, also check routing rules and the DNS path. Fake-IP is a domain-mapping mechanism, not a speed-boosting protocol. TUN expands the scope of traffic interception but doesn't guarantee faster connections; a change in performance may simply mean traffic that was previously direct is now proxied. Check connection logs to see which rule matched and which egress was used. Then follow the three-layer guide to troubleshooting slow speeds, checking the node, network path, and local device in that order.

Original Clash, Clash Meta, and mihomo

Project history and where capabilities come from

Original Clash established the YAML-based model for defining proxies, policy groups, and rules, which many GUI clients still use. After the original project stopped being maintained, existing installations may continue to run, but shouldn't be expected to receive new protocol support or compatibility fixes. An older client recognizing common configuration doesn't mean it can handle later protocol fields. When an unknown type appears, first identify the core actually handling the connection rather than relying on the window title.

Clash Meta developed as an extended core based on Clash and continued under the name mihomo. The Meta label used by users, extended capabilities in configuration files, and current mihomo documentation often refer to the same line of development, but older installers may still include an earlier implementation. This naming history explains the project's origins; it doesn't mean every client labeled Meta has the same capabilities. Check the core information and maintenance notes provided by the client.

mihomo extends protocol, rule, DNS, and traffic-interception capabilities, and serves as the connection core for various desktop and mobile clients. The GUI typically handles subscription downloads, overrides, and permissions. As a result, a feature may span both layers: the core may understand a field but the interface may not offer a toggle, or the interface may expose a setting that the current core doesn't support. Check the client and core documentation separately.

Compatible configuration structure doesn't guarantee support for every field

The three projects share basic structures such as proxy lists, policy groups, and rules, but extended protocols, rule behavior, and DNS fields are not fully backward-compatible. An older core may fail to load a newer configuration or silently ignore some fields. A newer core may expose issues in an older configuration because it enforces field constraints more strictly. Loading successfully is only the first step: also check which rules take effect, how domains resolve, and whether UDP traffic works.

Choosing a client and migrating an older setup

If you're choosing a client for the first time, start with Clash Plus, featured on the Download page, then check platform support and configuration requirements. On desktop, you can also compare Clash Verge Rev, FlClash, and Clash Nyanpasu. On mobile, check the Download page for format requirements for Clash Meta for Android, FlClash, or Surfboard. Clients don't all use the same configuration syntax. Accepting the same subscription link doesn't mean they can share the same full configuration file.

Clash for Windows and ClashX Meta are archived options in the download list and are no longer maintained. Before migrating, keep the original subscription URL, custom rules, overrides, and any necessary local settings. Don't overwrite the old directory. Import the subscription into the new client, then verify system proxy, TUN permissions, startup behavior, and ports separately. Don't run scripts from the old setup without reviewing them first; understand which configuration fields they modify.

Switch cores only when the client explicitly supports it. Different core builds may rely on specific control interfaces, startup arguments, and permission handling. Manually replacing files can cause the interface to show a different state from the core actually running. To verify a switch, check the running process and core information in the startup log, then confirm the configuration loaded. Don't rely only on the option shown in a settings menu; a leftover process may still be using the old port.

For migration troubleshooting, split the process into two stages: establish a connection using a minimal subscription configuration, then restore rules and overrides one at a time. This helps distinguish protocol compatibility issues from custom settings. For more on project history, see A comparison of features and compatibility across three generations of Clash cores. For an older desktop setup, follow the Clash for Windows migration guide to avoid mixing client management issues into protocol testing.

Subscription formats, field preservation, and configuration merging

A subscription URL doesn't imply a single file format

A subscription is an update endpoint, and its response might be full Clash YAML, a list of nodes, an encoded set of share links, or a configuration for another client. The same URL may return different formats depending on the request. So being able to open the link doesn't prove the current client can parse it. First confirm which client the subscription provider targets, then check the import message. If you get a webpage, login screen, or error text, resolve the access or authorization problem instead of changing YAML indentation.

A full configuration can contain proxies, policy groups, rules, and DNS settings. A node subscription usually describes only connection endpoints and relies on local configuration for policies and routing. Confusing the two can make rules disappear or leave policy groups without their referenced nodes. Some clients generate a template during import, temporarily hiding the problem until you switch clients. When inspecting a configuration, identify its top-level structure first, then check the protocol fields. Don't just search for node names.

Conversion changes the format; it can't invent missing information

Configuration converters map known fields into another syntax, but they can't recreate a public key, certificate name, plugin option, or transport path that wasn't in the source data. They may also drop capabilities that the target format doesn't support. After conversion, check the protocol type, address, port, identity, TLS, and transport options. Pay particular attention to Hysteria2, TUIC, and VLESS nodes with extended combinations.

Share links are useful for passing a single node, but a full configuration also includes rule order, policy-group dependencies, and local DNS behavior. Importing a set of node links into another client doesn't migrate the original network policy. Clients such as Surfboard have their own configuration requirements; changing the extension on a Clash YAML file won't make it compatible. If the formats don't match, ask the provider for a subscription intended for the target client rather than layering repeated conversions on top of one another.

Separate remote updates from local policies

Subscription updates usually replace remotely managed content. If you edit nodes or rules directly in the downloaded file, your changes may be lost on the next update. A safer approach is to use the subscription for node sources and local overrides for personal rules, DNS, and groups. The merge order varies by client: some local keys override remote ones, while lists may be appended or replaced. Check the merge documentation before making changes, then inspect the final configuration passed to the core.

The snippet below shows a minimal, parseable rules structure and doesn't include remote nodes. It illustrates how top-level fields relate to one another; don't use it as a replacement for your current subscription. In practice, names in proxy groups must refer to existing nodes or built-in policies. Rules are matched in order, so a broad rule placed too early can shadow more specific conditions. After editing, run the configuration checker provided by your client and confirm in the connection log that the expected rules matched.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: Default Policy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Default Policy

DNS settings are part of configuration compatibility

Fake-IP maps domains to virtual addresses so domain information can be preserved for use with rules and traffic interception; it isn't part of a node protocol. If you change DNS mode while importing a subscription, app behavior may change even if the proxy node stays the same. Check which resolver receives requests, whether the system or app uses encrypted DNS, and whether traffic interception covers the connections you expect. A single DNS toggle can't confirm the entire resolution path.

When troubleshooting merge issues, keep copies of the original content and final configuration, then compare the relevant fields after removing subscription credentials. Don't upload subscription URLs to unknown conversion services or leave authentication details in public logs. For domain-related issues, see DNS request paths and Fake-IP configuration. Change one group of settings at a time and verify the result before continuing, so update, merge, and DNS issues don't compound.

Choose a protocol for your use case and verify it

Desktop browsing, development, and sustained transfers

For everyday browsing and development tools, start with a configuration that the server operator maintains and your client fully supports. There's no need to begin with a complex transport combination. Browsers usually follow the system proxy, making their traffic easy to trace. Command-line tools and standalone runtimes may need their own proxy settings. If terminal access fails while web browsing works, first check whether the program is using the proxy instead of immediately switching protocols. Containers, virtual machines, and remote development environments may also have separate network settings.

For large downloads, check sustained throughput and recovery rather than just the initial peak. If a TCP option is stable, keep it as your baseline. If the path has significant packet loss and UDP is available, compare it with Hysteria2 or TUIC. Also watch interactive responsiveness and device load during the test. Confirm any improvement from bandwidth tuning without disrupting other traffic. Saturating the link briefly doesn't make a configuration optimal for every use.

Mobile use and real-time applications

Phones used on the move often switch networks, experience signal changes, and sleep in the background. Prioritize testing recovery after locking the screen, switching from Wi-Fi to cellular, and making the first request after a long idle period. Underlying connection migration can help in some cases, but verify that both the client and server actually enable it. A configuration that is fast on a fixed network may not suit mobile use if it requires a manual reconnect after every network change.

For games and calls, verify UDP forwarding, rule matching, and egress location. A node showing as available doesn't mean real-time traffic is using it. Some apps connect separately to authentication, media, and update services, which may match different rules. Check the actual connections before deciding whether to change protocols. For remote desktop, also evaluate screen updates, keyboard and mouse response, and recovery after brief packet loss; download speed alone isn't enough.

Servers, routers, and restricted networks

Servers and routers are often better suited to running mihomo directly, but you'll need to manage the process, permissions, configuration updates, and log rotation yourself. On resource-constrained devices, limit rule set size and connection-check frequency, and avoid leaving verbose logging enabled long enough to fill storage. Before making remote changes, keep a recovery path to the management interface, validate the configuration, and then reload the service. When moving a full desktop-generated configuration to a router, also check file paths, listening addresses, and permission differences.

If an office or guest network restricts UDP, first test a working TCP configuration rather than repeatedly retrying QUIC. If traffic goes through an additional proxy or gateway, check for multiple encapsulation layers and differences in address resolution. If a node fails only on one access network, test it on another network before inspecting the local configuration. If authentication fails at the same stage on every network, credentials, certificates, or protocol fields are more likely causes.

A consistent verification and rollback process

For initial verification, first check that the configuration loads, then establish a basic connection, and finally verify rules, DNS, and the target app. Record a clear result at each stage: which protocol the core recognized, which policy matched the request, and whether the actual egress was expected. If something fails, return to the most recent working configuration. Don't change the core, subscription source, and network mode at the same time. Separate an unexpected client exit from a protocol handshake failure; for the former, see Startup crashes and log troubleshooting.

1. Check the server-side protocol and client core, then verify identity, transport, and security-layer fields.
2. Test an ordinary website on a known-working network and confirm which policy actually matched.
3. Test sustained transfers, real-time apps, and recovery after idle periods separately; record where failures occur.
4. Change one variable at a time, repeat the same test, then decide whether to keep or revert the change.

Choose one primary configuration and one verified fallback. Ideally, the fallback uses different underlying transport conditions, so both options don't depend on the same failed path. Keep credentials and configuration sources trustworthy. To install a client, choose your platform on the Download page, where Clash Plus is featured. For setup steps, return to the Getting Started Guide; for general issues, see Frequently Asked Questions. A protocol defines how a connection works; it can't guarantee results on every network.