Clash Protocols & mihomo Core Guide

1. Protocols, transport and traffic routing: where each fits

Start by separating the layers in a connection

An outbound entry in a Mac client involves more than one technology. At the innermost layer is the app's request—for example, a browser loading a page or a terminal connecting to a code repository. The client first decides whether to intercept it, then selects a policy group based on its rules, and finally sends the request to a server through a specific outbound. A proxy protocol defines how the client and server authenticate, identify the destination and transfer data. TCP, UDP, TLS, WebSocket, HTTP/2 and QUIC belong to different transport or security layers. Treating all these terms as interchangeable protocols can send you down the wrong path when importing a config or troubleshooting.

For example, VLESS can use different transports, but if the server is configured for WebSocket, entering the correct address and user ID is not enough—you cannot simply switch to plain TCP. The path, request headers, TLS setting and server name may all be required to establish the connection. A protocol label in the interface usually identifies just one layer. To confirm compatibility, check the protocol, transport, security settings and any extensions together. If these fields are already in the subscription, keep them as provided. Do not combine settings from tutorials for different servers.

System proxy and TUN are traffic-routing methods, not protocol types

The system proxy tells apps that follow macOS proxy settings to send connections to a local proxy port. TUN creates a virtual network interface and routes matching traffic through it. These determine how traffic reaches the client, not whether the client uses SS or Trojan to connect to a server. The same outbound can serve system-proxy traffic or traffic captured by TUN. So if a terminal app cannot connect, changing protocols may not help: the request might never have reached the client. Check the connection logs first, then identify whether the issue lies with traffic capture, rules or the outbound.

Rule, Global and Direct modes are not protocols either. Rule mode chooses an exit based on domains, addresses and other conditions; Global mode sends captured connections to a single policy; Direct mode typically connects them straight to their destinations. Even in Global mode, apps that ignore the system proxy are not automatically captured. Conversely, TUN can capture traffic while still applying rules—you do not have to send every request to a remote server. For setup details, see the macOS TUN enhanced mode guide to check permissions and routing.

Assess security alongside practical requirements

Encryption, server authentication and config privacy address different risks. A TLS connection does not mean certificate verification can be disabled, and a random identifier does not make a subscription URL safe to share. Before choosing a protocol, confirm who operates the server, whether its certificate is trusted and whether the subscription comes from an expected source. A proxy server can generally observe connection destinations and timing; HTTPS encryption in the app still protects content. Do not treat certificate checks as an optional setting to leave disabled just to get a connection working.

As you compare the options below, distinguish between what a protocol allows and what the current implementation supports. A protocol may be designed for UDP forwarding, but that does not mean every server, plugin or subscription converter implements it fully. An interface toggle cannot add capabilities the server does not have. Choose based on the core's supported features, server requirements and connection logs—not on how many technical acronyms appear in a name.

2. Shadowsocks and VMess: different design trade-offs

Shadowsocks: a simple design for encrypted proxying

Shadowsocks, often abbreviated to SS, creates an authenticated, encrypted forwarding channel between client and server. A basic config typically consists of a server address, port, encryption method and password, keeping the number of parameters relatively small. It suits users with known server details who want to avoid combining multiple transport layers. Older stream-cipher methods and newer AEAD methods differ in security and compatibility, so not every link labelled SS represents the same implementation. Choose a modern method supported by both your core and server; fewer settings alone do not make a better choice.

Traditional AEAD and Shadowsocks 2022 are not interchangeable just by changing the encryption method name. Shadowsocks 2022 has specific key format and length requirements, and the client and server must use compatible settings. If an imported config reports an invalid key length, check the original config and method—do not truncate the key or pad it with extra characters. Some SS configs also require a plugin. That is an additional dependency, and not every client can run the same plugin. A Mac GUI's ability to read basic SS fields does not mean it includes the runtime environment an external plugin needs.

SS has relatively little overhead in its basic form, but that does not make it faster on every network. Hardware acceleration for the cipher, server load, packet loss on a single connection and local network quality all affect performance. UDP forwarding also requires server support and matching client settings. If web pages load but calls or games fail, check UDP support, destination rules and NAT behavior separately. A successful TCP request does not prove the entire outbound is working.

VMess: identity-based authentication with flexible transports

VMess comes from the V2Ray ecosystem and is designed around user authentication and data transfer. An outbound is commonly configured with a user ID and encryption options. VMess supports different transports, but that means more settings must match. If the server uses TLS with WebSocket, the client must match the user ID, TLS server name, path and any required headers. VMess and its underlying transport have distinct roles. Troubleshoot them separately rather than treating every failed handshake as a protocol failure.

Older tutorials often show fields tied to historical authentication methods. Modern configs typically use VMess AEAD, and older combinations may no longer be accepted by current cores. Do not add obsolete parameters just to match an old screenshot. Incorrect system time can also affect authentication, so if your Mac has been offline for a long time, check the date and time in System Settings. For an authentication error, check the clock, user ID and server requirements. If the log stops at certificate or transport negotiation, address that layer first; the failure alone does not prove the ID is wrong.

If your existing SS service is stable and does not require a special plugin, there is no need to switch just because another protocol has more fields. If a VMess service already provides a complete, maintained config, test it as-is before considering a replacement. Added complexity is only useful when it meets a real need; otherwise, it just creates more settings to manage. If you cannot change the server, focus on confirming that the subscription works with your current core, and keep a known-good outbound for comparison.

3. Trojan, VLESS and TLS settings

Trojan: authentication over a TLS connection

A typical Trojan setup uses TLS as its secure outer channel, with password authentication and proxy requests handled inside it. It builds on the established certificate and TLS ecosystem, so although the config may appear to boil down to an address, port, password and server name, it depends heavily on the certificate chain, domain and server setup. The server address identifies the connection endpoint; the TLS server name is used for identity verification and related processes. They may differ, but should not be swapped arbitrarily. If the subscription specifies a domain, replacing it with an IP can change DNS resolution or cause certificate name verification to fail.

The client's SNI or server-name field is not the same as the HTTP Host header. SNI is used during the TLS handshake; Host is part of the HTTP request. In setups that use an outer transport such as WebSocket, both may be present. Filling every field with the same domain by default does not guarantee compatibility and may obscure how the config is meant to work. For certificate errors, check the system clock, certificate validity dates and intermediate certificate chain, then verify the name in the subscription. Permanently skipping certificate verification removes an important safeguard for confirming the server's identity.

VLESS: a lightweight protocol with configurable security layers

VLESS is another proxy protocol from the V2Ray ecosystem, designed to keep the protocol itself relatively lean. It does not provide built-in data encryption in the same sense as SS, so connections typically rely on TLS or another explicitly configured security layer. That means “VLESS is lightweight” should not be taken to mean “turn off security settings for more speed.” If the server requires TLS, configure the client to match. A user ID authenticates a user; it does not encrypt content or protect a connection by itself.

VLESS can be combined with different transports and extensions, and compatibility varies by core implementation. Reality settings, client fingerprints and flow-control options each have specific requirements; a guide for one combination will not apply to every VLESS outbound. Flow control is not a universal speed boost. It only helps when the server, transport and client implementation all support the same settings. Do not invent a public key, short ID or other value missing from the subscription and expect a connection to work. These parameters must come from the matching server config.

Troubleshoot certificate errors separately from protocol issues

A TLS connection can fail before authentication even begins. An expired certificate, name mismatch, broken system trust chain or interference from a network device can prevent Trojan or TLS-enabled VLESS from connecting. These errors are not necessarily caused by the proxy protocol. If regular HTTPS sites also have problems in your browser, first check your Mac's clock and network. If only one outbound fails, inspect the server config. For help identifying the cause, see HTTPS certificate errors: causes and troubleshooting. Do not try to bypass the issue by installing a root certificate from an untrusted source.

For Trojan and VLESS, differences in actual speed are often overshadowed by the outer TLS layer, transport and server network. Initial handshakes, connection reuse, congestion control and destination response times may dominate. A faster page load once does not prove one protocol is always better. Mac users are usually better off starting with a complete config, a trusted certificate and a core that clearly supports it, then comparing performance on the same network and against the same destinations. Maintenance effort is part of the cost too: a setup that needs manual fixes after every update may be less reliable over time than a mature config.

4. Hysteria2, TUIC and UDP network conditions

QUIC offers a different transport foundation

Hysteria2 and TUIC both use QUIC, which runs over UDP, but they are different protocols. You cannot import one as the other by changing its type name. QUIC combines security handshakes, reliable streams and congestion control, and allows multiple streams to share a connection, reducing TCP-level head-of-line blocking between streams. Each reliable stream still delivers data in order, and network congestion still affects total bandwidth. QUIC does not eliminate packet loss; it offers different recovery and scheduling behavior. Its benefits depend on UDP being available on your network and on compatible implementations.

Some guest networks, corporate Wi-Fi and hotspots restrict or throttle UDP, or impose short session timeouts. A TCP-based outbound working on the same network does not mean QUIC should work too. On a Mac, keep a known-good TCP-based config as a baseline while testing the UDP path. If the connection only fails after waking from sleep, consider expired NAT mappings or client reconnection behavior instead of assuming the credentials are wrong. The same protocol can behave differently on a home network and public Wi-Fi because the network conditions differ.

Hysteria2 bandwidth settings are not speed-test results

Hysteria2 is designed for transport conditions that can include high latency and packet loss; its congestion-control behavior depends on the client and server config. Some configs specify upload and download bandwidth to influence sending behavior. These values are not a promise of available speed from the server. Setting a higher download bandwidth does not make downloads faster; a value far above the real bottleneck can cause queuing, packet loss or interference with other apps on the same network. Use a realistic estimate of sustained link capacity and follow the server's limits instead of copying someone else's numbers.

Hysteria and Hysteria2 are different protocol generations. Renaming the type is not enough to migrate an older config; authentication fields, obfuscation options and transport settings must also match. If the importer identifies the type as the older protocol, first get a config output intended for mihomo. A client showing that the config was saved only means it accepted the text—it does not prove the server handshake succeeded. Check the connection logs to see whether the attempt reached authentication and whether it failed during UDP setup, TLS verification or protocol authentication.

TUIC: connection multiplexing and UDP forwarding

TUIC also runs over QUIC and focuses on multiplexing proxy connections and carrying TCP and UDP traffic. Different protocol generations may not be compatible, so authentication fields and forwarding options must match the server. Some UDP forwarding modes trade off reliability, latency and encapsulation overhead. Reliable delivery is not automatically the best choice for real-time apps: audio or game data that arrives too late may be useless, while file transfers need complete delivery. Keep the mode recommended by the server, then test with the apps you actually use.

Treat these protocols as options to test, not default choices for every situation. If UDP is reliable on your network and packet loss noticeably affects connections over long distances, compare them against a baseline. If UDP support is uncertain or you frequently switch between office networks, keep a TCP-based fallback outbound. A good choice minimizes variables you cannot control; it should not require reconfiguration every time you change networks just to use a particular transport.

5. Connection speed, resource use and mobile battery life

Break “fast” into three measurable factors

Connection speed includes at least three things: time to establish a connection, sustained throughput and responsiveness under load. Browsing depends on the first response and how quickly many small resources load; large downloads depend more on sustained throughput; remote terminals and video calls are more sensitive to jitter and interruptions. A low latency-test result does not mean an outbound is faster for every task. A client’s latency test usually measures the request time to a chosen address—not just the physical round-trip time—and may include DNS, handshake and destination-server processing.

For a fair protocol comparison, keep the Mac, network, destination and test window the same, and use servers in the same location with similar resources if possible. If the configs use different servers, the results primarily reflect two end-to-end paths, not the protocols alone. Repeated tests are also affected by caching, connection reuse and changes in server load. Record first-load, repeat-visit and sustained-transfer behavior separately, but do not treat the best single result as typical. It is more useful to track recurring timeouts, reconnects and pauses during normal work.

CPU, memory and network overhead do not have a single ranking

CPU load comes from encryption, decryption, protocol parsing, data copying and network-stack processing. Hardware acceleration can differ between Apple silicon and Intel, and the client build matters too. TUN adds a virtual interface and traffic processing; DNS, rule matching, connection logging and verbose logs also use resources. You cannot attribute all battery or resource changes after enabling TUN to the protocol, or compare memory use between two different GUI clients as a direct measure of the protocols they run.

In macOS Activity Monitor, track CPU, memory and energy use for both the client and any related core processes. Keep the task consistent during testing; do not compare a full download on one setup with an idle client on another. If memory keeps growing, check connection count, log volume and subscription size before assuming a protocol leak. Higher CPU use during a fast transfer may be normal. If usage remains high while idle, investigate repeated reconnects, unusual DNS requests or routing loops, and use the Help Center to narrow down the symptoms.

On mobile, wakeups and network conditions matter more for battery life

Mobile battery drain is not just about encryption. Cellular radio activity, keepalive frequency, background reconnects, signal strength and NAT timeouts can all have a bigger impact. Long-lived connections may reduce repeated handshakes, but frequent keepalives can also wake the radio more often. UDP-based options may work well on some networks but require constant session rebuilding on others. There is no fixed battery ranking based on names like SS, Trojan or QUIC, and Mac CPU benchmarks do not translate directly to phones.

If your Mac connects through a phone hotspot, account for the hotspot device's battery use too. A large transfer can increase network load on both the Mac and the phone. For everyday use, test typical tasks and sleep/wake behavior instead of just running a full-bandwidth speed test. Reducing unnecessary speed tests, overly frequent policy-group checks and debug logging can sometimes help more than changing protocols. Do not shorten health-check intervals without a reason: faster failure detection means more background requests, so balance the two against how often you need to switch.

Your final setup can use different policies for different tasks. Browsing, development tools and real-time apps may not need the same outbound, but each group should have a clear purpose. Avoid splitting rules into too many groups just for testing. Establish a stable baseline first, then test one alternative against a specific issue. This makes results more reliable than changing the protocol, DNS, TUN and policy groups all at once.

6. How original Clash, Meta and mihomo relate

The core runs the network; the GUI client manages it

A core in the Clash ecosystem parses configs, matches rules and handles network connections. A GUI client provides the menu bar, subscription management, system proxy, permissions and settings interface. They work together but are not the same thing. Clash Plus, Clash Verge Rev and FlClash are clients; their protocol support depends on the core they bundle or call. A client interface update may only change how it works, without updating every protocol implementation. Check the downloads page for installers and client options; Clash Plus is a good place to start with a first setup.

Original Clash established the widely used YAML config conventions for outbounds, policy groups and rules. The original open-source core and other releases that once shared the Clash name are not identical; their features differ. Clash Meta extended protocol and networking capabilities in the ecosystem, and the project later took the name mihomo. When a subscription or guide mentions Meta, it often refers to this development lineage, not a separate “Meta plugin” you need to install. Knowing the history helps you interpret references, but you still need to check actual feature support.

Similar structure does not mean every field is compatible in both directions

mihomo retains much of the Clash config structure while adding protocol types, rule capabilities and network settings. If an original core cannot recognize a newer outbound, that is a feature limitation—not necessarily a YAML indentation error. Conversely, migrating an older config to a newer core may be affected by deprecated fields, changed defaults or stricter validation. Loading the config is only the first step. Also check that rules match as expected, DNS works, policy-group references resolve and TUN actually captures traffic from the target app.

Before migrating, save your working config and client settings. Then confirm whether the new client imports the original subscription, a merged config or an exported runtime config; they may not be the same. A GUI client may override ports, DNS, the control interface and TUN settings before starting the core. Copying an old runtime file directly can carry over environment-specific settings that no longer apply. First import the subscription with the client's default network settings and confirm a basic connection. Then restore custom rules and overrides one at a time to avoid introducing multiple sources of failure.

Use a small config to check syntax and defaults

This snippet shows common mihomo config fields for mode, ports and log level. It contains no remote outbound and cannot establish a proxy connection on its own. Before merging it, check that the full config does not already define the same top-level keys. The mixed port accepts local HTTP and SOCKS connections; use the port the client actually listens on. It is not the remote server port, and not all clients use the same default.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

If the log reports an unknown protocol type, first check whether the core supports it and whether the subscription outputs the right format. If it cannot find a policy or proxy name, check references and subscription filters. If the config runs but rules do not work, check rule order and client overrides. For a detailed comparison, see mihomo vs. original Clash: feature comparison. Do not assume every error means the core is too old, and do not repeatedly replace the entire config without a backup.

Apple silicon and Intel installers are built for different processor architectures, not different protocols. Running a build suited to your Mac can avoid unnecessary translation, but protocol availability still depends on the core. Archived clients such as ClashX Meta can be useful as references for existing setups; for long-term use, consider their maintenance status and macOS compatibility. A maintained client that clearly shows core status is generally more useful for future troubleshooting than one chosen for appearance alone.

7. Clash YAML, proxy lists and subscription conversion

A subscription URL does not tell you what format it returns

A subscription link is an entry point for retrieving config data. The response may be a complete Clash YAML file, a YAML file containing only outbounds, a set of encoded share links or sing-box JSON. A URL suffix or link name is not enough to identify the format, and some services return different content based on request parameters or client identifiers. If an import fails, first determine whether the error occurred while downloading, parsing the content or validating the config at runtime. A successful download that returns HTML may be a login page, error page or access notice—not YAML that needs fixing.

A complete config typically includes outbounds, policy groups, rules and other runtime settings; a proxy list may contain only the fields needed to connect. A client that imports the list successfully does not mean it includes routing rules suited to every user. Some clients fill in missing parts with their own template; others require you to specify them. If outbounds appear after import but expected policy groups do not, check the subscription type and template rather than re-entering the server password. Config completeness and the number of outbounds are separate issues.

What encoding, conversion and merging actually do

Base64 is an encoding, not encryption or a proxy protocol. Encoded content may contain SS, VMess, Trojan and other share links, each with its own fields. Decoding the text restores its original representation; it does not create rules, DNS settings or policy groups. Share-link formats also vary in which parameters they can express, and older parsers may not understand newer extensions. A link that imports in one client may not be interpreted identically by every client.

A subscription converter maps one data model to another and may also apply templates, rename entries or filter them. Conversion can drop fields that the destination format cannot represent, such as specific transport extensions, fingerprint options, policy-group behavior or DNS routing semantics. sing-box JSON and Clash YAML differ in top-level structure and some behavior—not just brackets and indentation. Changing a file extension or translating field names word for word will not produce a reliable config. Validate the converted result against the core you actually use.

Check privacy boundaries and update behavior before you begin

Subscriptions usually contain credentials that can be used to connect, and the URL itself may include access tokens. Do not post a full URL in public screenshots, discussions or an unverified conversion service. Remote conversion may expose subscription contents to a third party, so understand who handles the data and where it goes. If the provider offers a native mihomo or Clash Meta format, use it to avoid an extra conversion step. For technical help, share only the error category, protocol type and a redacted config structure—never your password, user ID or full subscription URL.

Update behavior also affects config maintenance. Edits made directly to a generated subscription file may be overwritten the next time it updates. Client-provided overrides, merges or extensions are better places for local rules. However, merge order varies between clients, and appended lists can create duplicates or change rule order. Confirm which fields are managed by the subscription and which by the client before deciding where to make changes. This is especially important for rules: an earlier, broad rule can prevent a later, more specific rule from ever matching.

If only some outbounds disappear after an update, check filters, rename rules and supported types. If they all disappear, check the returned content and download status. If the update succeeds but behavior changes, see whether the template or overrides changed too. Keep a redacted field list for before-and-after comparisons rather than storing multiple credential-bearing files in a shared sync folder. For an overview of how three common formats map to one another, see Subscription link formats and conversion before adding a conversion step.

8. Choose a protocol by use case and verify it layer by layer

Establish a stable baseline before adding protocol alternatives

For everyday browsing and office work, start with an outbound that has complete server details, works reliably on your current network and is supported by your client. A mature SS, Trojan, VMess or correctly configured VLESS setup can all be good options. There is no need to standardize on one protocol. If your current config works well on the networks you use, migrate to address a specific problem—such as a blocked transport, certificate maintenance or an app that needs UDP—not just because another protocol is newer. Keep the original config so you can compare the change against a known baseline.

For development tools, first check how their traffic reaches the client. If the browser works but the terminal does not, see whether the tool reads the system proxy. Configure its own proxy option or environment variables if needed, and consider TUN only after that. Do not start by changing protocols and running repeated speed tests; the request may not be reaching the client at all. Run the command below in the macOS Terminal to view current system proxy settings. It does not test the remote protocol or prove that a command-line tool follows those settings. Confirm the listening port in the client’s settings.

scutil --proxy

For video calls, voice and gaming, pay close attention to UDP forwarding, jitter and recovery after disconnects. First confirm that the app is being captured, then check which rule it matches and whether the outbound supports UDP. Hysteria2 and TUIC are worth testing only if the network allows UDP and the server config matches. For a Mac that frequently switches between home, office and guest networks, a TCP-based fallback is often more practical. A policy group's health check tests its chosen target; it cannot guarantee that every app will work.

Validate the setup with one repeatable task

After each change, run the same operation against the same destination. First confirm that the client loaded the config, then open the target app and check for a connection log. If there is no log, check the system proxy, TUN permissions and the app's own settings. If a request appears but uses the wrong policy, check rule order and DNS resolution. If the policy is right but the handshake fails, then check the protocol, authentication, certificate and network path. This breaks “no internet” into diagnosable stages and avoids changing DNS, ports and protocols all at once.

Recovery and fallback are part of the choice

After you open your Mac from sleep, the client may need to restore interfaces, routes or connections. If problems occur only after waking, first confirm that the network is back, then switch once to a known-good outbound or reconnect the client and check the logs. If failures keep recurring, check service permissions, network extensions and whether another VPN is also changing routes. Multiple traffic-capture tools running at once can cause routing loops or priority conflicts; changing protocols will not fix that. When you quit the client, also confirm that the system proxy has been reset so it no longer points to a local port that is not listening.

Narrow down your choice using four checks: the current core supports it, server parameters are complete, it works on your usual networks, and it handles real tasks reliably. Compare performance and battery use only after those conditions are met. If a new combination needs extensive manual fixes to keep working, factor that maintenance cost into your decision. For a first-time setup, follow the Quick Start Guide. Look up specific symptoms in the Help Center, and unfamiliar terms in the glossary. This guide provides a framework; the best evidence is a repeatable result on your Mac, your current network and the apps you actually use.