What this Ubuntu installation guide covers

Installing Clash Verge Rev on Ubuntu is straightforward once you separate the desktop client from the proxy service it controls. The application provides a graphical interface for profiles, policy groups, connections, logs, and system integration. The core still needs a usable configuration and at least one working outbound connection before normal applications can reach the destinations you intend to route.

This guide is written for Ubuntu desktop users who want a predictable first setup rather than a collection of commands copied from unrelated Linux distributions. You will learn how to identify the correct package architecture, install the application without weakening system security, import a subscription safely, select a policy group, enable the appropriate proxy mode, and confirm the result with observable tests. The same reasoning also helps when you later troubleshoot package upgrades, DNS behavior, or applications that do not respect the system proxy.

A successful installation has several independent parts. The binary must launch, the Clash-compatible core must run, a profile must be downloaded and activated, the selected policy must have a healthy outbound, and your application must actually use the listener. If one layer is missing, the interface may look normal while every request still follows a direct route. Keeping these layers separate makes Ubuntu proxy troubleshooting much faster.

Ubuntu requirements and preparation

Before downloading anything, update your local system and confirm the basic environment. A current Ubuntu desktop release is preferable because newer releases generally provide more recent WebKit, NetworkManager, tray integration, and permission behavior. You do not need to install a separate desktop environment for this guide, but a graphical session is useful because Clash Verge Rev is designed as a desktop control panel rather than a headless daemon.

Open Terminal and inspect the system architecture:

dpkg --print-architecture
uname -m
lsb_release -a

Most modern Intel and AMD computers report amd64 or x86_64. ARM-based Ubuntu hardware may report arm64 or aarch64. These labels are related but not interchangeable in every release archive, so read the asset name and release notes carefully. Installing a package for the wrong architecture usually fails immediately, while forcing an incompatible binary can create confusing dependency or launch errors.

You should also decide where your subscription URL will come from. Clash Verge Rev does not create proxy nodes by itself. You need a configuration provider, a profile generated by infrastructure you administer, or a local YAML configuration that contains valid proxies and policy groups. Treat subscription URLs like passwords: they may grant access to traffic resources, expose usage information, or identify your account. Do not publish them in screenshots, issue trackers, shell history, or public chat rooms.

Security note: Download only from a release source you can verify. Avoid repackaged AppImage files, “cracked” builds, and random binary mirrors that provide no checksum, release history, or publisher identity.

Choose the right Linux package format

Linux releases commonly appear as .deb, AppImage, or compressed archives. A Debian package integrates most naturally with Ubuntu: it can register files with the package database and make future removal more orderly. An AppImage is portable and convenient when you lack administrator access, but desktop menu registration, sandbox behavior, and file permissions may require additional manual work. A compressed archive gives you the most control and the least integration, which makes it better suited to experienced users who already maintain local application directories.

For a first Ubuntu installation, prefer a matching .deb package when one is available. If the project publishes only an AppImage, keep it in a dedicated directory such as ~/Applications, mark it executable, and avoid running it from a temporary Downloads folder that may later be cleaned automatically. Whichever format you choose, compare the release version and architecture with the information shown on the trusted release page.

Download and verify Clash Verge Rev

Use the official Clash download page or the project’s documented release channel to locate the Ubuntu build. Do not select an asset simply because its filename contains “Linux.” Confirm three details: the version is the one you intend to install, the architecture matches your machine, and the package format is supported by your Ubuntu release.

After downloading, list the file and calculate a checksum if the publisher provides a reference value:

cd ~/Downloads
ls -lh
sha256sum clash-verge-rev*.deb

A checksum does not prove that a website is trustworthy by itself; it proves that your local file matches the published value. Source authenticity still depends on obtaining the reference checksum through a channel you trust. If the value differs, stop and download again rather than installing the file. A partial download, proxy cache issue, or malicious replacement can all produce a mismatch.

Keep the original package until the application has launched and your configuration has been tested. This gives you a known installer for rollback or offline reinstallation. Once you are satisfied, move old packages into an archive directory or remove them according to your local storage policy.

Get the installer

Install the Ubuntu package

For a Debian package, you can use Ubuntu’s graphical software installer or the command line. The graphical route is familiar: open the downloaded file, review the package details, and choose Install. The command-line route provides clearer error output and is often easier to repeat on multiple machines.

  1. Open the download directory: use cd ~/Downloads or navigate to the folder containing the package.
  2. Install the package: run sudo apt install ./clash-verge-rev*.deb, adjusting the filename if the shell wildcard matches more than one file.
  3. Read dependency messages: let Ubuntu resolve normal package dependencies, but do not approve unrelated software that you did not expect.
  4. Launch the application: open Clash Verge Rev from the application menu or start it from the terminal to observe launch errors.
  5. Confirm the process: check that the interface appears and that the core status does not immediately report a crash or configuration failure.

If apt reports missing dependencies, do not download random libraries from third-party websites. First refresh the package index and retry:

sudo apt update
sudo apt --fix-broken install
sudo apt install ./clash-verge-rev*.deb

Use --fix-broken carefully and review the proposed changes before confirming. On managed computers, package installation may be controlled by an administrator or endpoint policy. In that situation, follow the organization’s software request process instead of bypassing it with a portable binary.

If you are using an AppImage

When the available Linux release is an AppImage, create a predictable location and make the file executable:

mkdir -p ~/Applications
mv ~/Downloads/Clash.Verge.Rev*.AppImage ~/Applications/clash-verge-rev.AppImage
chmod +x ~/Applications/clash-verge-rev.AppImage
~/Applications/clash-verge-rev.AppImage

Some Ubuntu systems require additional FUSE compatibility libraries for older AppImage runtimes. If the application complains about FUSE, consult the release documentation for the exact Ubuntu package required by that version. Do not disable security controls globally just to make an unknown binary start. An AppImage that launches successfully may still need a desktop entry, tray permission, or a manual startup shortcut, so package integration is part of the decision rather than an afterthought.

Complete the first launch safely

On first launch, Ubuntu may display a permission prompt, a desktop integration notice, or a security warning depending on how the application was packaged. Read each prompt in context. A system proxy toggle normally changes desktop network settings; a TUN or service integration may request elevated privileges because it creates a virtual interface or modifies routing behavior. Approve a permission only when it matches the feature you are intentionally enabling.

Allow the interface to finish initializing before importing a profile. Look for the core status, listener information, and profile section. If the application opens but the core repeatedly stops, inspect the logs before changing several settings at once. Common causes include an invalid configuration, an unsupported rule syntax version, an occupied local port, or a missing runtime dependency.

Close other proxy clients during initial testing. Two applications may attempt to own the same mixed port, SOCKS port, DNS port, or virtual tunnel. Running multiple TUN implementations at the same time can produce loops where traffic enters one tunnel and is captured again by another. Disable competing VPNs temporarily so the first test has one clear dataplane.

Import a subscription or local profile

Open the Profiles section in Clash Verge Rev. A remote subscription is usually added by pasting a URL into the profile import field. Give the profile a recognizable name that includes the provider or environment, but never include the full secret URL in the name. Start the download and wait for the application to parse the response.

  1. Copy the subscription URL: obtain it from your provider dashboard or your own configuration service, not from a public comment.
  2. Add the URL: paste it into the profile import field and check that the address uses HTTPS when the provider supports it.
  3. Download the profile: wait for completion and review any parser or format error shown by the application.
  4. Activate the profile: select the newly downloaded profile so its proxies, groups, DNS settings, and rules become active.
  5. Protect the credential: remove the URL from clipboard history or shared notes if the computer is used by other people.

A local YAML file can be useful for testing or for a configuration you maintain yourself. Import it through the same profile interface when possible. Avoid editing a generated subscription directly because a later refresh may overwrite your changes. If you need custom rules, use the application’s override, patch, or provider-specific customization mechanism and keep those changes documented.

After activation, inspect the profile rather than assuming every node is usable. Check whether policy groups contain members, whether the selected group has an actual proxy, and whether the configuration includes rules that match your intended traffic. A profile can download successfully while containing expired endpoints or an empty selector group.

Select a policy group and configure the system proxy

The next task is choosing how traffic should be routed. Most profiles expose a selector group with names such as Proxy, Auto, or a provider-specific label. Select a known healthy option first. Automatic latency selection can be useful later, but a fixed node makes initial troubleshooting easier because the route does not change while you test.

For ordinary desktop applications, begin with Rule mode. Rule mode lets local or approved destinations remain direct while selected domains use the proxy group. Global mode sends nearly all supported traffic through the chosen proxy and can be useful as a temporary diagnostic. If a destination works in Global mode but fails in Rule mode, the problem is often rule order, DNS classification, or an incorrect policy group—not necessarily a dead node.

Enable the system proxy only after confirming that the profile and listener are active. The system proxy normally points HTTP and HTTPS applications to a local mixed port, often bound to a loopback address such as 127.0.0.1. Your actual port may differ, so read it from Clash Verge Rev rather than copying a number from an old tutorial.

Important: A system proxy is not the same as a full-device tunnel. Terminal tools, sandboxed applications, containers, games, and software with its own network stack may ignore desktop proxy settings.

When to consider TUN mode

TUN mode creates a virtual network interface and captures traffic at a lower level than the desktop system proxy. It can help with applications that do not honor HTTP or SOCKS settings, but it also changes DNS handling, route tables, and the boundary between direct and proxied traffic. For that reason, it should be an escalation step rather than the first switch you flip.

Before enabling TUN, record the working system proxy state and close competing VPN clients. Read the application’s permission prompt carefully, because a service or privileged helper may be required. Start with the default TUN settings, test a small set of destinations, and then inspect the Connections or Logs view. If local websites, printers, corporate services, or private subnets stop working, review the bypass rules and routing mode instead of assuming the proxy node is broken.

Containers and virtual machines deserve special attention. A TUN interface on the Ubuntu host does not automatically guarantee that every container namespace will follow the same route. Docker networking, host mode, explicit proxy variables, and container DNS configuration can each change the result. Test from the actual application environment when your goal is to support a development tool or service running outside the host desktop.

Verify that the proxy connection works

Verification should use more than one signal. First check the Clash Verge Rev dashboard: the core should be running, the active profile should be visible, and the selected policy group should show an available outbound. Then open the Connections or Logs view and generate a request from a browser. You should see the destination hostname, the rule that matched it, and the policy or node used.

Command-line checks are useful because they reveal whether a terminal application inherits the system proxy. Test the local listener with an explicit proxy request:

curl -I -x http://127.0.0.1:7890 https://example.com

Replace 7890 with the HTTP or mixed port shown in your client. A successful response proves that the local listener accepted the request; it does not prove that every destination is permitted or that your browser uses the same path. For a direct comparison, run a request without -x and compare the result, timing, and corresponding log entries.

For applications that rely on environment variables, export the proxy explicitly:

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

Some tools honor ALL_PROXY or require a SOCKS URL instead. Consult the tool’s documentation and avoid assuming that a successful browser test covers every runtime. Node, Python, Go, Git, package managers, IDEs, and containerized applications may each implement proxy support differently.

A practical verification checklist

  • Core status: confirm that the Clash-compatible core remains running for several minutes.
  • Profile status: confirm that the intended profile is active and contains populated policy groups.
  • Listener test: use curl or another documented client to send a request through the local port.
  • Log evidence: verify the hostname, matched rule, policy group, and outbound node in the connection view.
  • Browser test: test a destination that should use the proxy and one that should remain direct.
  • Application test: repeat the request from the actual terminal, IDE, container, or desktop application you care about.

Do not rely on an IP-location page alone. Such pages may use cached data, multiple endpoints, or browser-specific APIs. A log entry showing the intended rule and outbound is more useful because it tells you what the client actually did. If the request succeeds but the matched rule is unexpected, fix the routing policy before treating the setup as complete.

Troubleshoot common Ubuntu problems

The application does not launch

Start it from a terminal and read the error output. Check the package architecture, executable permissions, missing libraries, and desktop session type. If you installed an AppImage, verify that it is executable and stored on a local filesystem. If a Debian package partially installed, use the package manager to inspect its state rather than deleting files manually. Rebooting may refresh tray integration, but it will not fix an invalid binary or incompatible dependency.

The profile downloads but cannot be activated

Inspect the response format and parser error. Some URLs return an HTML login page, an expired subscription notice, or a provider-specific format that the selected core does not support. A profile may also use syntax from a newer core than the one bundled with your client. Refresh the application through a trusted release channel and ask the provider for a compatible export if the error persists.

The dashboard is running but no traffic appears

This usually means the application is not using the system proxy, the browser has a separate proxy configuration, or the selected mode routes the tested destination directly. Confirm the system proxy toggle, inspect the browser’s network settings, and generate a request while watching the log view. If you are testing a command-line tool, use explicit HTTP_PROXY and HTTPS_PROXY variables or the tool’s own proxy option.

The request appears in logs but fails during DNS or TLS

DNS mode, fake-IP behavior, local resolvers, and firewall rules can all affect the result. Do not change all of them at once. First test a different policy node and compare the log error. Then check whether the hostname resolves consistently and whether Ubuntu, the browser, and the Clash core are using different resolvers. TLS failures can also come from incorrect system time, certificate inspection, or an application trust store that does not contain an organization’s required root certificate.

Another process already uses the listener port

Find the process holding the port:

ss -ltnp | grep 7890

Use the actual port shown in Clash Verge Rev. Shut down the competing proxy or assign a different unused port in the client settings. Avoid changing ports repeatedly without updating browser, terminal, and service configuration; inconsistent port values create a second problem that looks like a routing failure.

Keep the Ubuntu installation maintainable

After the first successful setup, write down the client version, package format, listener ports, active profile name, and any custom overrides. This small record makes future troubleshooting much easier, especially after an Ubuntu upgrade or subscription refresh. Keep a backup of custom rules without including secret subscription URLs. If a profile is generated remotely, document the provider’s expected update process instead of hand-editing generated content.

Review profiles periodically. Remove expired nodes, confirm that policy groups still point to valid members, and check whether a provider has changed rule syntax. Automatic refresh is convenient, but it can also replace a carefully selected node or remove an override. If stability matters, test a refreshed profile before making it your only configuration.

Use the least powerful mode that solves the problem. Rule mode with the system proxy is easier to inspect and less disruptive than TUN mode. TUN is valuable for applications that bypass desktop settings, but it deserves explicit bypass rules for local networks, private services, and administration interfaces. When you stop using the client, disable system proxy or TUN before diagnosing unrelated Ubuntu connectivity problems.

Why a rule-based Clash client is useful on Ubuntu

Some consumer VPN applications make the first click easy but hide the decisions that matter later. For example, a one-button client may connect a browser while giving no useful explanation when a package manager, terminal tool, or local service follows a different route. Other lightweight proxy launchers accept a server address but provide limited profile management, weak connection logs, or no practical way to keep domestic and remote destinations separate. These limitations become noticeable on Ubuntu, where developers often combine browsers, SSH, Git, containers, IDEs, and system services on the same machine.

Clash Verge Rev takes a more observable approach. Profiles make configuration refreshes repeatable, policy groups let you select or test different outbounds, rule mode supports split routing, and the Connections view shows how a hostname was classified. When a terminal command fails, you can compare its environment with the active listener instead of guessing whether the provider, DNS resolver, or application ignored the proxy. That visibility is especially valuable for Ubuntu users who want control without maintaining every route manually. If you are looking for a client that combines a graphical workflow with inspectable Clash-compatible behavior, downloading the appropriate build is a natural next step.

Download Clash for free and browse freely →