Why Developer Traffic Needs a Better Clash Workflow
Modern development depends on many different network services at the same time. A single terminal session may connect to GitHub over HTTPS, open an SSH connection to a server, download packages from npm, pull an image from Docker Hub, and call an AI coding assistant within a few minutes. These services do not always share the same routing requirements. Some work best through a nearby proxy node, some should use a direct connection, and others require a stable long-lived TCP session.
When Clash is enabled without developer-specific rules, the symptoms are familiar: a GitHub clone remains at zero percent, npm install stalls while resolving packages, an SSH session disconnects after a few minutes, or Docker reports a timeout while contacting its registry. Switching to Global Mode may appear to solve one problem, but it can also send private infrastructure, internal company domains, and local services through an unsuitable proxy.
This guide presents a practical workflow for connecting Clash with Git, SSH, package managers, Docker, and AI coding tools. The examples use a Mihomo-compatible YAML configuration, but the same principles apply to desktop clients such as Clash Verge Rev and other interfaces that support rule-based routing.
Workflow Goal
Keep developer services stable by separating proxy-required traffic, direct traffic, private networks, and latency-sensitive terminal connections.
1Build a Developer-Friendly Routing Model
The most reliable Clash setup begins with a clear routing model rather than a long list of random domain rules. Think about traffic in four groups: services that must use a proxy, services that should remain direct, private infrastructure that must never leave the local network, and connections that need a consistent policy for their entire lifetime.
Proxy public developer services when necessary
GitHub, GitLab, npm registries, container registries, and hosted AI platforms may be slow or unreachable from some networks. If your local route to these services is unreliable, send the relevant domains through a dedicated policy group. Avoid using a frequently changing “automatic” group for long-running operations when possible. A node that changes during a large repository clone can interrupt the connection even if every individual node is fast.
Keep private and local destinations direct
Private IP ranges, local development servers, VPN endpoints, and company domains usually belong on DIRECT or a dedicated corporate policy. Proxying them can create unexpected authentication failures, break split DNS, or expose internal hostnames to an external server. These rules should appear before broad proxy rules because Clash evaluates rules from top to bottom.
The policy name in this example, DeveloperProxy, must exist under proxy-groups. A simple group can contain several nodes, while a more advanced group can use health checks. For development work, stability is often more important than the lowest single-request latency. A node with predictable packet loss and a clean IP reputation is usually better than a faster node that fails every few minutes.
Pro Tip: Start Narrow
Begin with rules for the services that actually fail. Broadly proxying every domain can make local package mirrors, private registries, and internal dashboards slower or inaccessible.
2Hands-On Setup for Git, SSH, and Terminal Tools
After creating the basic rules, configure the tools that run outside your browser. Browser proxy settings do not automatically control command-line programs. Clash’s system proxy mode may help applications that honor operating-system proxy variables, but Git, OpenSSH, Docker, and language package managers each have their own behavior.
For HTTPS repositories, Git can use an HTTP or SOCKS proxy. If your Clash mixed port is 7890, the following commands configure a proxy for Git globally:
HTTP/1.1 is not always required, but it can make troubleshooting easier when a network, proxy node, or middlebox handles HTTP/2 poorly. Verify the settings before testing:
If GitHub is reachable directly but slow through the proxy, remove the proxy settings and rely on Clash’s transparent or system-level routing instead:
SSH does not understand an HTTP proxy by itself. The most portable method is to use ProxyCommand with a local SOCKS listener. Add a host-specific entry to ~/.ssh/config:
Here, 7891 represents Clash’s SOCKS port. Confirm the port in your client rather than assuming the default. Test the connection with verbose output:
Some networks block outbound port 22. GitHub supports SSH over port 443 through ssh.github.com, which can be useful when a firewall allows HTTPS but rejects standard SSH:
Use the alias for a remote such as git@github-443:owner/repository.git, or define the repository remote with the full host alias. Keep private servers on a separate host entry so they can use a corporate route or direct connection.
Node.js tools often use environment variables or their own configuration files. For npm, inspect the current registry and proxy values first:
To use a reachable registry through Clash, configure it explicitly:
If Clash is already operating in TUN mode and your rules correctly route npm domains, an application-level proxy may be unnecessary. Duplicate proxy layers can cause certificate errors or confusing bypass behavior. The same principle applies to Yarn, pnpm, pip, Cargo, and Go: choose either reliable system-level interception or a clearly defined application proxy, then test it with a small request.
Once these settings are applied, perform a controlled test: clone a small repository, open an SSH session, install one package in a temporary directory, and compare the result with Clash disabled. Record the selected node, latency, and error message. This makes it much easier to distinguish a Clash rule problem from a registry outage or an expired credential.
3Docker, Registries, and AI Coding Tools
Docker requires special attention because the Docker CLI and the Docker daemon may run in different environments. Setting a proxy in your shell does not necessarily configure the daemon. On Linux, the daemon may be managed by systemd; on Windows and macOS, Docker Desktop has its own engine and proxy settings.
Docker image pulls and the daemon proxy
If docker pull times out while ordinary browser traffic works, configure the proxy where the daemon can access it. A typical Linux systemd drop-in looks like this:
Do not blindly copy this configuration when Docker runs inside a virtual machine or a containerized desktop environment. In that case, 127.0.0.1 refers to the Docker environment itself, not necessarily the host running Clash. You may need the host gateway address, and the Clash listener must allow connections from that interface. Restrict listener exposure with a firewall; never expose an unauthenticated proxy port to a public network.
Private registries and no-proxy exceptions
Many teams use an internal registry such as registry.company.example. Add it to NO_PROXY and create a higher-priority DIRECT or corporate rule. Otherwise, image pushes may travel through a public node and fail TLS verification, private DNS resolution, or access control.
AI coding assistants
AI coding tools may use multiple endpoints for authentication, model requests, telemetry, extension downloads, and update checks. Do not assume that allowing one domain is enough. Inspect the tool’s official network documentation, then add only the required domains to a dedicated policy group. Keep API keys in environment variables or the tool’s credential store rather than placing them in Clash profiles, which may be synchronized or shared.
When an AI extension fails inside an editor but its command-line counterpart works, compare the environment inherited by the editor. GUI applications launched from a desktop menu may not read the same shell profile as a terminal. Configure the editor’s proxy setting or start it from a shell for testing. Also check whether certificate inspection, restricted WebSocket support, or an unstable node is interrupting streaming responses.
4Diagnose Timeouts Without Guesswork
Developer networking problems become much easier to solve when each layer is tested separately. Start by confirming that Clash itself is running and that the selected policy group has a healthy node. Then test DNS, TCP reachability, TLS negotiation, and the application protocol in that order.
- Check the listener: Confirm the HTTP and SOCKS ports in the Clash dashboard and verify that the process is listening on the expected local address.
- Check DNS behavior: Use
nslookupordigto compare answers with Clash enabled and disabled. In fake-IP mode, remember that the operating system may display synthetic addresses by design. - Check HTTPS: Run
curl -I -v https://github.comand inspect whether the request uses the expected proxy and completes TLS negotiation. - Check Git: Use
GIT_CURL_VERBOSE=1 git ls-remote URLto see redirects, authentication failures, and connection resets. - Check SSH: Use
ssh -vvvto confirm that the configuredProxyCommandis being executed. - Check Docker: Run
docker infoand inspect daemon logs. A shell proxy setting does not prove that the daemon has received it.
Common errors also provide useful clues. A DNS failure usually points to resolver configuration or a missing domain rule. A connection reset often indicates an unstable node, blocked port, or protocol mismatch. A TLS certificate error can result from a wrong system clock, HTTPS interception, or a private registry being sent through the wrong route. A successful connection followed by an application-level authorization error is usually not a Clash problem at all.
Security Warning
Do not disable TLS verification globally to “fix” package, Git, or Docker errors. Find the incorrect route, certificate chain, clock setting, or corporate trust configuration instead.
Finally, review the Clash connection log after reproducing one failure. Look for the actual domain contacted by the application rather than relying only on the visible service name. A GitHub clone may contact release assets, a package manager may use a CDN, and an AI extension may call several authentication endpoints. Add a rule only after confirming the destination and its correct routing policy.
Developer Clash FAQ
Should I use Global Mode for Git and npm?
Global Mode can be a useful diagnostic step, but it is rarely the best permanent configuration. It may confirm that a service needs a proxy, yet it also routes private repositories, local services, and unrelated traffic through the same node. Prefer rule-based routing with a dedicated developer policy group and explicit DIRECT exceptions.
Why does Git work in a browser but fail in the terminal?
The browser may automatically use Clash’s system proxy while Git does not. Configure Git’s proxy settings, use TUN mode, or use a terminal environment that respects the relevant proxy variables. For SSH remotes, configure an SSH-specific ProxyCommand; an HTTP proxy setting alone will not control OpenSSH.
Why does Docker still fail after I set HTTP_PROXY?
The Docker daemon may be separate from your shell and may not inherit its environment. Configure the daemon or Docker Desktop directly, verify the host address used to reach Clash, and add private registries and local networks to NO_PROXY. Restart the daemon and confirm the values in docker info.
How can I keep long SSH sessions stable?
Use a consistent proxy policy, select a node with low packet loss, enable ServerAliveInterval, and avoid automatic node switching during a deployment. If port 22 is blocked, use an officially supported SSH-over-443 endpoint where available. Keep server credentials and private keys outside the Clash configuration.
Once the routing rules, application settings, and diagnostic process are aligned, Clash becomes more than a browser proxy. It becomes a predictable traffic layer for the entire development workstation, allowing Git, SSH, package managers, Docker, and AI tools to use the route each one actually needs.