How To Set Up Clash Verge Rev External Controller On Windows

What the Clash Verge Rev external controller does

If you searched for Clash Verge Rev external controller on Windows, you probably want more than the desktop dashboard provides. A browser-based controller lets you inspect active connections, switch proxy groups, review traffic, and change selected runtime settings without keeping the full Clash Verge Rev window in front of you. It is especially useful when the client runs in the background, when you manage a Windows machine remotely, or when you prefer a lightweight dashboard over repeatedly opening the application.

The external controller is an API endpoint exposed by the Clash Verge Rev core, usually Mihomo. A compatible dashboard connects to that endpoint over HTTP and sends authenticated requests. The dashboard itself is only the visual layer; it does not provide proxy nodes, create a subscription, or replace the Mihomo core. Your profile, rules, proxy groups, DNS behavior, and operating mode still come from Clash Verge Rev.

This separation is important when troubleshooting. If the dashboard cannot connect, the problem may be that the controller is disabled, the address is wrong, the API secret does not match, or Windows Firewall is blocking the listening port. If the dashboard opens but traffic is routed incorrectly, the controller is working and you should investigate the active profile, rules, groups, or core logs instead.

This guide uses a safe local-first approach: enable the controller, bind it to a suitable address, create a secret, connect a dashboard, test the API directly, and only then consider remote access. Do not expose an unauthenticated controller to the public internet. An external controller can change routing behavior, so anyone who reaches it may gain meaningful control over your proxy process.

Prerequisites and Windows port planning

Before changing settings, make sure Clash Verge Rev is installed and can already start normally on Windows. Import or select a working profile, confirm that the Mihomo core is running, and note whether system proxy or TUN mode is enabled. The external controller depends on the core process; opening the Verge Rev interface alone does not guarantee that an API is listening.

You also need three pieces of information:

• Controller address: the IP address and port where the API listens, commonly a loopback address such as 127.0.0.1:9090.
• API secret: a long random value used by the dashboard to authenticate requests.
• Dashboard URL or application: a controller interface that supports the API format exposed by your Mihomo version.

For a dashboard running on the same Windows computer, binding to 127.0.0.1 is normally the safest choice. It accepts requests from local applications but does not intentionally listen on every network interface. If you need to connect from another device on your private LAN, you may need a LAN address such as 0.0.0.0 or the computer’s private address, depending on the client version. That choice increases the attack surface and should be paired with a secret, a restrictive firewall rule, and a trusted network.

Choose a port that is not already occupied by the mixed port, SOCKS port, redir port, or another local service. The controller port is separate from the port used by browsers and applications for proxy traffic. For example, an HTTP mixed port might be 7890, while the external controller listens on 9090. Confusing these two ports is one of the most common reasons a dashboard fails to connect.

Enable the external controller in Clash Verge Rev

Open Clash Verge Rev on Windows and locate the settings area for the active core or profile. The exact label can vary between releases: you may see External Controller, External Controller Address, Controller, or a Mihomo-related advanced setting. Do not assume that a setting in a downloaded YAML file is active until the current profile has been selected and the core has reloaded it.

Set the controller address to a local endpoint first:

127.0.0.1:9090

Then enter a strong secret in the controller secret field. Use a generated value rather than a short word, a username, or the same password used for Windows. A practical secret can contain upper- and lowercase letters, numbers, and symbols. Store it in a password manager because dashboards normally need the exact value, including every character and capitalization choice.

Some users prefer editing the YAML configuration directly. In that case, the relevant structure commonly looks like this:

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-secret"

The exact configuration schema can differ between Clash-compatible cores and client releases, so treat this as a structural example rather than a promise that every build exposes identical fields. If you edit a generated profile, a subscription refresh may overwrite the change. A persistent settings panel, an override, or a dedicated local configuration is usually more reliable than modifying a temporary generated file.

After saving, reload the profile or restart the Mihomo core if Verge Rev requests it. Watch the client’s logs for messages indicating that the external controller started successfully. A syntax error, an invalid port, or a port collision may prevent the core from starting even though the desktop application itself remains open.

Verify that Windows is listening

Use PowerShell to check whether the selected port is listening:

Get-NetTCPConnection -LocalPort 9090 -State Listen

If the command returns a listening entry, Windows has a process bound to that port. You can identify the owning process with:

Get-NetTCPConnection -LocalPort 9090 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id <PROCESS_ID>

If no entry appears, return to the controller setting and confirm that the core was reloaded. If another process owns the port, select a different controller port and restart the core. A browser error such as “connection refused” usually means that nothing is listening at the address, not that the dashboard has a rendering problem.

Connect a browser dashboard with the secret

Open the dashboard you intend to use and create a new connection. Most dashboards ask for a controller URL and an API secret. For a local Windows setup, enter:

Controller URL: http://127.0.0.1:9090
Secret:        your-long-random-secret

Some interfaces request only the base URL, while others expect a complete API path. Start with the base URL unless the dashboard documentation explicitly requires a path such as /version. Do not add the mixed proxy port, and do not use https:// unless you have deliberately configured TLS in front of the controller. A local Mihomo controller commonly serves plain HTTP on the loopback interface.

When authentication is implemented through an HTTP header, the dashboard typically sends the secret as a bearer token:

Authorization: Bearer your-long-random-secret

If the dashboard reports an unauthorized response, compare the secret character by character. Check for an extra space, quotation marks copied from a configuration file, a missing symbol, or a secret belonging to a different profile. If it reports a network error, compare the address and port first. These are separate failure classes and should not be debugged interchangeably.

A local browser dashboard may also be affected by browser security rules. If the dashboard is hosted on a different origin, the controller must permit the dashboard’s origin through its external-controller CORS setting when supported. A page that loads successfully can still fail its API requests because of a CORS policy. Look at the browser’s developer console and Network panel: a blocked preflight request points toward CORS, while a refused TCP connection points toward binding, port, or firewall configuration.

For a dashboard on another device, replace 127.0.0.1 with the Windows computer’s private address, for example 192.168.1.20:9090. Confirm the Windows network is marked Private only when that matches your actual environment, and avoid testing through hotel, school, or public Wi-Fi where other clients may share the same segment. Remote administration should happen through a trusted VPN or a similarly controlled private path, not by forwarding port 9090 from the router.

Test the API directly and troubleshoot failures

Before blaming the dashboard, test the controller with PowerShell. The version endpoint is a useful low-risk check because it confirms reachability and returns core information without changing proxy groups:

$headers = @{
  Authorization = "Bearer your-long-random-secret"
}

Invoke-RestMethod `
  -Uri "http://127.0.0.1:9090/version" `
  -Headers $headers

A successful response normally contains version information in JSON. You can also request the current configuration or connections after the version test works:

Invoke-RestMethod `
  -Uri "http://127.0.0.1:9090/proxies" `
  -Headers $headers

Invoke-RestMethod `
  -Uri "http://127.0.0.1:9090/connections" `
  -Headers $headers

Use these read-only requests to establish a baseline. If the version request succeeds but the dashboard remains blank, the endpoint is reachable and the likely causes are an incompatible dashboard API, a CORS restriction, a browser extension, or a dashboard-side parsing problem. If the version request fails, use the following sequence.

• Connection refused: check that Mihomo is running, that the address is correct, and that no other service has taken the port.
• 401 Unauthorized: check the bearer secret and remove accidental quotation marks or whitespace.
• 404 Not Found: verify that the dashboard is speaking the API format supported by your core and that you did not paste an incorrect path.
• Timeout from another device: check the bind address, Windows Firewall, private network profile, and whether the two devices can reach each other.
• Browser CORS error: allow the dashboard origin only if you trust it, or run the dashboard locally so both components share a suitable origin.

Windows Firewall deserves special attention. A rule created for a Public network may not behave as expected on a Private network, and a rule that allows the proxy mixed port does not automatically allow the controller port. If you must allow LAN access, create the narrowest rule possible: the specific TCP port, the Private profile, and trusted local addresses. Do not create a broad “allow any application on all networks” exception just to make a dashboard work.

Once the API responds, use the dashboard to select a proxy group and then confirm the change in Clash Verge Rev’s logs or connections view. Test one ordinary request, observe its rule and selected node, and then test a second domain with a different expected policy. This proves that the controller is not merely reachable; it is controlling the same running core that handles Windows traffic.

Secure the controller and keep the setup maintainable

The controller secret should be treated like an administrative credential. Never publish it in screenshots, screen recordings, support tickets, shell history, or a shared dashboard URL. If you believe it has leaked, replace it immediately, reload the core, and remove old dashboard profiles from browsers and other devices. A secret protects the API, but it does not make an internet-exposed HTTP endpoint a good public service.

Keep the controller local unless you have a clear operational reason for LAN access. If you manage a Windows PC from another room, a private VPN is preferable to router port forwarding. If a reverse proxy is unavoidable, place authentication and TLS in front of it, restrict source addresses, and understand which headers are forwarded. Do not rely on an obscure URL path as the only protection.

Document the working values in a private note: the controller port, whether the bind address is loopback or LAN, the dashboard name, the core version, and the date the secret was rotated. When Clash Verge Rev updates, test /version and the dashboard again. Core APIs can evolve, and a dashboard that worked with one Mihomo release may display incomplete data after an API change.

For recovery, return to the simplest state: bind to 127.0.0.1, use a new secret, reload the core, and verify the version endpoint from the same computer. Only after local access works should you reintroduce LAN binding, firewall changes, or a remote dashboard. This layered rollback prevents several independent variables from hiding the original fault.

Compared with lightweight proxy tools that hide their management API, or dashboards that require a separate tunnel and offer little visibility into rules, Clash Verge Rev gives Windows users a practical combination of Mihomo observability, browser-based control, selectable proxy groups, and explicit authentication. You can see whether a request is actually reaching the expected policy instead of guessing from a disconnected toggle. If you want that workflow on your own Windows system, the next sensible step is to choose the appropriate Clash client build and begin with a local, protected configuration.

Download Clash for free and browse freely →