Before You Start: Install the Client and Get a Subscription

Have a client installed and ready to open, along with a Clash- or mihomo-compatible subscription URL from your provider. The client reads the configuration, runs the core, and handles requests; installing the app alone doesn't provide usable nodes. Import a URL only after confirming on your account page, in your purchase history, or in your provider's instructions that it's a subscription link. A regular web address, account login page, or single node share link may not work as a complete configuration.

On Linux, run the command below to check your CPU architecture. An output of x86_64 usually means amd64 or x64; aarch64 usually means arm64. Choose an installer that also matches your distribution: Debian- and Ubuntu-based systems commonly use DEB packages, while Fedora and similar distributions use RPM. Check the downloads page for supported architectures rather than relying on the file extension alone. Install a graphical client with your distribution's package manager, then launch it from the applications menu.

uname -m

For your first setup, turn off the system proxy and transparent proxy features in other proxy clients to prevent conflicts over local ports or desktop proxy settings. Leave your network's gateway and DNS settings as they are, and don't change your router at the same time. This guide follows a short verification path: Rule mode, one clearly selected outbound, and the system proxy. If your current network can't open regular websites, restore basic connectivity before importing a subscription.

Step 1: Import a Subscription and Enable the Configuration

Open Clash Verge Rev and select Subscriptions or Profiles in the sidebar. Paste the full subscription URL from your provider into the address field, then click Import. Keep the entire URL, including any query parameters. When copying it, leave out quotation marks, line breaks, and trailing punctuation from chat messages. Wait for the import to finish; repeated clicks can create duplicate configurations.

After a successful import, a configuration card should appear, usually showing its name and an update option. Select the card or choose Enable from its menu to make it the active configuration. The selected state varies by version and may be shown with a border, checkmark, or active-profile label. A successful download alone isn't enough: make sure the configuration is in use. Then open Proxies and check that policy groups and selectable nodes are listed before continuing.

If your provider supplies a local YAML file, use the configuration page's file import option, select the file, and enable it. The file must contain a configuration structure the client can read; renaming a plain text file to config.yaml won't create nodes. Remote subscriptions can usually be updated from their configuration card, while local files may not have an update source. Manage the two accordingly.

If an import fails, first identify the type of error. A download timeout means the client couldn't retrieve the content; a format or parsing error means the content couldn't be read as a configuration; an account error means you need to check your status with the provider. You can check whether the subscription URL is reachable in a browser, but don't paste it into a public online converter or share its response. When asking for help, include only the error type and redact the URL, account details, and node credentials.

This step is complete when the configuration is active and the Proxies page shows its policy groups and nodes. If the configuration card is there but the list is empty, check that the configuration is enabled and whether the subscription provides only Provider entries. Provider references are a configuration issue; see the configuration reference. Don't keep toggling the system proxy while the list is empty.

Step 2: Choose Rule Mode and a Proxy Node

Once the configuration is enabled, find the mode selector on the home or Proxies page and choose Rule. Rule mode applies the rules in the active configuration to decide whether traffic entering the core connects directly, uses a proxy, or takes another action. It's a good starting point because you can check which rule each request matches during verification, instead of sending all requests through a single outbound from the start.

Next, find the policy group that controls proxy outbounds. Its name depends on the subscription and may be Proxy, Proxy Selection, or something else; there isn't a universal button name. Select the group to view its options, then choose a specific node. If an option is another policy group, open it too and follow the chain to the final node or intended auto-select group. Don't mistake DIRECT for a proxy node: it means the request connects directly to its destination.

If the page has a latency test, use it to rule out unresponsive options. The result doesn't guarantee that websites will load: the test URL, node protocol, and target site can all affect real-world performance. For initial troubleshooting, keep one outbound selected and complete the request tests below. Changing nodes, modes, and DNS at the same time makes it harder to find the cause of a problem.

What Rule, Global, and Direct Modes Change

Global sends traffic that enters the core through the Global policy group, which can help you check whether a site's behavior is affected by rule selection. After switching, check the outbound selected in that group; it may differ from the one used in Rule mode. Direct sends requests that enter the core straight to their destinations and can be useful for a quick comparison. Global mode doesn't automatically capture every app: requests that never enter the core remain untouched by this setting.

Mode and traffic capture are separate things. For now, stay in Rule mode and note the selected policy group and outbound. Next, use the system proxy to route browser requests through the core. If you're unsure what policy groups, rule matches, or DIRECT mean, see the glossary. The configuration reference covers the full rule syntax; you don't need to rewrite rules for your first connection.

Step 3: Enable the System Proxy and Connect

Return to the client home or settings page, confirm the core is running, and find Mixed Port. The commands below use 7890 as an example; use the port shown in your client. The mixed port accepts HTTP and SOCKS proxy connections. Browsers and terminal tools must send requests to this endpoint for the core to handle them using the selected mode.

Turn on the client's System Proxy switch. On a Linux desktop, this usually changes the proxy settings for the current session, but whether an app follows those settings depends on the app. Open your system's network proxy settings and check that the address is 127.0.0.1 and the port matches the client. If your browser has a separate proxy extension, set it to use the system proxy or specify the same address and port so it doesn't keep pointing to an old client.

Open a new browser tab and visit the site you're testing. If the browser keeps using an old connection, close that tab and open a new one; restart the browser if needed. The System Proxy switch indicates that the client has requested a change to desktop settings, not that every app is using the proxy. Next, check both the local listener and a real request rather than judging by the switch's color.

Set a Proxy Explicitly for Terminal Commands

Terminal programs don't usually read the desktop system proxy automatically. For the first test, use curl --proxy to specify the address explicitly; there's no need to edit your shell startup files yet. This affects only the current command and makes it easy to compare with a direct connection. If your client's mixed port isn't 7890, replace the port in the command below. If curl isn't installed, install it with your distribution's package manager first.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -I https://example.com/

Leave TUN Off for the First Connection

TUN uses a virtual network device to capture traffic from apps that don't follow the system proxy, but it also adds permissions, routing, and DNS considerations. Leave TUN off for your first setup. Test the browser and an explicitly proxied command before deciding whether you need it. TUN in Clash Verge Rev may require a service and authorization; use the client's service setup or authorization option. Don't run the entire graphical client as root just to enable one feature.

If you later need TUN, first turn off other VPNs and transparent proxies, confirm the client's service is working, then enable TUN and test again. Network paths can differ in containers, remote desktop sessions, and servers; avoid changing the default route over a remote session. For details on tun.stack, DNS hijacking, and route exclusions, see the configuration reference. These aren't required for the basic connection steps in this guide.

Step 4: Verify the Port, Requests, and Rule Matches

Verify the setup in three stages: confirm the core is listening, check that a request gets a response through the proxy, and make sure the browser uses the expected route. These checks aren't interchangeable. An open port only confirms that the local endpoint is available; a site loading could still mean it connected directly. Match command output against the client's connection logs to confirm that the configuration is working.

Check the Local Port First

Run the command below in a Linux terminal. If your port is different, update the filter. You should see a line containing LISTEN and the matching address and port. If there's no output, check that the core is running and confirm the port in the client, then look for errors in the startup logs. Don't change nodes yet: the request hasn't reached node selection.

ss -lnt 'sport = :7890'

If the port is already in use, check whether an old client or another mihomo instance is running. Don't kill processes you don't recognize. Close a confirmed old client, or choose an unused port in the current client. If you change the port, update both the browser settings and test command so they match. For initial testing on your own machine, you usually don't need to allow LAN connections.

Test an Explicitly Proxied Request

Run the curl command from the previous step and check whether you receive HTTP response headers. When using an HTTP proxy to access HTTPS, you may first see a response for establishing the tunnel, followed by the target site's response. A successful tunnel alone doesn't mean the target page loaded. A response such as 403 means the request was rejected; it isn't a port failure. For certificate errors, check the system clock, certificate setup, and the specific error. Don't hide the problem by disabling certificate verification.

example.com is only an example for demonstrating the test. A response from it doesn't mean every site is reachable or that the request went through a remote node. Next, replace the test address with the site you actually need to reach, then open the client's Connections or Logs page. Find the matching domain and check its rule, policy group, and final outbound. If you see DIRECT, the core chose a direct connection for that request.

Compare Browser and Terminal Results

If curl receives a response from the target when you specify a proxy but the browser fails, first check whether the browser follows the system proxy, whether an extension overrides its settings, and whether an old tab is reusing an existing connection. If the browser works but a regular terminal command fails, check the terminal's environment variables before importing the subscription again. Apps can use different traffic capture methods, so test against the same site.

If the port is listening but an explicitly proxied request still times out, try another node in the same policy group and test again. Check the logs for connection failures or DNS errors. If some sites work and others don't, check the rules and DNS. Troubleshoot in this order: port → proxy settings → DNS → rules → node. Change one thing at a time. For more troubleshooting paths, see Troubleshooting.

Quit, Update, and Start Again

When you're done, turn off the System Proxy in the client first. If TUN is enabled, turn it off before quitting as well. Force-quitting the app can leave the desktop proxy pointing to a local port, so your browser may lose access even though the client is closed. If that happens, restore your previous settings in the system network proxy page and check your connection; you don't need to reinstall the client right away.

The next time you start the client, check whether your active configuration and policy group selections were saved, then enable the traffic capture method you need. Update subscriptions from the configuration card's update option. If node names change after an update, check the policy group selection again. Subscription updates and client software upgrades are separate: one updates the configuration source, the other replaces the app. Don't treat either as a sign that the other is complete.

That's the end of the basic setup. For YAML fields, Providers, overrides, and merges, see the configuration reference. For explanations of terms in the interface, visit the glossary. Keep your working settings as a baseline, change one option at a time, and retest against the same site to make future troubleshooting easier.

Clash Verge Rev Setup GuideImport a Subscription and Test Your Connection