A developer proxy is a routing choice, not a single switch
Developer tools look like one workflow because they are launched from one terminal, but their network requests often come from different processes and use different transports. A Git fetch may use SSH on port 22, a package manager may use HTTPS, and a browser opened for authentication may follow macOS or Windows system proxy settings instead of the shell’s environment. Even within one command, DNS lookups, API requests, archive downloads, and redirects can take separate routes. A desktop Clash client showing “connected” therefore does not prove that every command-line program is using the path you intended.
Start with a small mental model: Clash exposes local listeners, applies rules to connections it can observe, and sends matching traffic to a chosen policy group or directly to the network. Applications may reach those listeners in different ways. An HTTP client can honor HTTPS_PROXY; a SOCKS-capable tool can use a local SOCKS port; and a TUN interface can capture eligible IP traffic without each application knowing about a proxy. None of these mechanisms automatically configures every tool, resolves every DNS issue, or overrides a company’s approved network controls.
For most development machines, the least surprising starting point is an explicit local proxy for tools that support it, with a predictable policy group in Clash. Add TUN only when you have identified traffic that bypasses application-level proxy settings or need a consistent route for programs that do not provide proxy controls. This staged approach makes debugging easier: if a request fails, you can distinguish a bad local listener, an ignored environment variable, a rule mismatch, a DNS problem, or an upstream connection failure rather than changing several layers at once.
Before changing anything, write down what should work and how you will test it. For example, you might need GitHub HTTPS clones, GitHub SSH authentication, and Homebrew formula downloads to use the same approved egress, while internal source control and private mirrors should remain direct. That is a more useful target than “make the terminal use Clash,” because it describes observable outcomes and helps you avoid routing private work traffic through an unintended provider.
Choose an explicit proxy first, then consider TUN
An explicit proxy is usually the easiest first test. In your Clash client, confirm the active profile, the selected policy group, and the local HTTP or mixed-port listener. The exact port depends on the profile and client; do not assume a familiar default is enabled. Check the client’s settings or configuration for the listener address, commonly a loopback address such as 127.0.0.1, and the actual port number. Confirm that no other service has taken that port before exporting it to a shell.
In a disposable terminal session, set proxy variables for programs that understand them. For example, use HTTP_PROXY and HTTPS_PROXY with the local HTTP-compatible listener, and set ALL_PROXY only when the application supports the scheme you specify. Some tools accept lowercase variable names as well, while others read only their own configuration. Keep credentials out of shell history, and avoid placing sensitive proxy URLs in shared project files, build logs, or screenshots.
Test a harmless HTTPS endpoint before changing Git or Homebrew. Use a command-line client that reports connection details, and compare a request with the proxy variables set against one made in a clean environment. Then inspect Clash’s connection or log view to see whether the request arrived and which rule and policy handled it. A successful response without a corresponding Clash connection may mean that the application ignored the variables, used a separate network stack, or reused an existing connection. A failed response with a visible connection points the investigation toward the rule, DNS result, policy group, or upstream path.
TUN mode becomes useful when an application has no proxy support, when a child process ignores the shell environment, or when you need to observe and route eligible traffic more consistently across tools. It creates a virtual network interface and captures traffic at the system level, so it can also affect applications beyond your terminal. Enable it only in a client and operating system that support the required permissions and network components. On managed devices, obtain approval before installing or enabling a network extension, service, or tunnel driver.
Treat TUN as a second diagnostic layer, not a magic repair button. First verify that explicit proxy access works. Then enable TUN and repeat the same test, watching for duplicate paths, DNS differences, and conflicts with corporate VPNs or other packet filters. If TUN makes previously direct traffic visible but breaks a private host, refine the policy using the organization’s documented network requirements rather than adding broad exceptions by guesswork. A focused explanation of capture behavior is available in the Clash TUN mode deep dive.
Make Git over HTTPS and SSH predictable
Git HTTPS and Git SSH are different network paths, even when they reach the same hosting service. HTTPS commonly uses the proxy settings supported by Git’s HTTP transport. SSH normally connects to the SSH server and port configured by the remote URL; it does not automatically inherit an HTTP proxy variable. This distinction explains a common pattern: git clone https://... succeeds while git clone git@... stalls, or SSH works while Git’s HTTPS requests bypass the expected local listener.
Begin by checking the remote URL for the repository and the transport it selects. If the URL starts with an HTTPS scheme, inspect Git’s effective proxy configuration as well as the environment. Git can have system-wide, user-level, and repository-level settings, and a narrower setting can override a value you thought was global. Use Git’s configuration inspection commands to identify where a proxy value came from. When testing an environment-only setup, temporarily unset any Git-specific proxy value so you are not unknowingly comparing two different configurations.
If your organization permits SSH through the network path you are using, configure SSH separately and narrowly. A common option is a local SOCKS-capable proxy through an SSH configuration entry using a supported proxy command, but the exact command and syntax depend on the installed SSH implementation and the listener protocol. Do not paste a configuration copied from an unrelated operating system without checking that its helper exists and that it invokes the intended local port. Keep the change limited to the relevant host alias rather than rewriting every SSH connection on the machine.
Another approach for some hosting providers is SSH over an alternative port, if the provider officially supports it and your network policy allows it. That is not equivalent to disguising traffic or bypassing a firewall rule: use only documented endpoints and ports that are explicitly permitted. If a provider does not offer an approved SSH route, use the organization’s supported HTTPS transport or ask the network administrator for the correct access method. A proxy cannot repair an invalid key, missing repository permission, or a server-side policy denying the connection.
Test SSH in layers. First run an SSH diagnostic with verbose output and note whether the client resolves the host, reaches the expected address, opens a socket, offers the expected identity, and receives an authentication response. The exact wording varies, but the sequence is informative. A timeout before key exchange points toward routing, port reachability, or a proxy command problem. A public-key denial after the server responds is an authentication or authorization issue, not a reason to keep changing Clash rules. Confirm which key the SSH agent offers and whether the repository account has permission.
When a Git request fails, compare the repository’s transport with a direct SSH diagnostic to the same host. Then use the Clash connection log to verify whether the connection was captured and which rule selected its route. Hostname-based rules can be helpful, but the actual destination may be an IP address after resolution, and an SSH proxy command may create a connection that differs from the one you expected to see. Keep specific source-control rules above broad catch-all rules; otherwise a generic match can silently send a development connection through an unintended group. Our Clash rule routing best practices guide explains why rule order matters.
Configure Homebrew without breaking local workflows
Homebrew downloads more than one kind of resource. A formula or cask request can involve repository metadata, an API endpoint, a source archive, a prebuilt bottle, and a redirect to a storage or CDN host. Those requests may not all share the same hostname. A formula lookup that completes quickly does not prove that its bottle download will use the same route, and a failure during installation may happen after the initial metadata step has already succeeded.
First confirm that the shell running Homebrew has the intended proxy variables and that the listener responds. Then run a routine, low-impact Homebrew operation and observe the corresponding connections in Clash. If the package manager reports that it cannot fetch an archive, record the failing host and the stage of the operation before editing rules. A network error for a redirected storage host may need a different explanation from a DNS failure for the initial API endpoint. Avoid adding every hostname in a log to a permanent rule set; identify which ones are required for the operation and whether they are official endpoints.
Homebrew and its dependencies may invoke other programs, including Git, curl, or language-specific downloaders. Each can read a different configuration source. That is why one successful command does not guarantee that the entire installation chain uses the proxy. Check the environment inherited by the process, inspect any Git remotes involved, and compare the command’s output with Clash’s connection history. If the shell is launched from an IDE, a GUI terminal, or a task runner, verify that it inherited the variables you set in your interactive shell profile. A terminal opened before a profile change may still carry an older environment.
Keep private taps and internal package sources in mind. A blanket proxy setting can send internal development traffic to a public egress when it should remain on a company network or approved VPN. Conversely, a direct route may be unavailable for a public archive on a restricted connection. Use policy rules that reflect the actual ownership and requirements of each destination, and test both public and private resources after making a change. Avoid putting a personal subscription URL, account token, or private mirror credential into a script committed to a repository.
If Homebrew works in a normal terminal but fails in a build agent or continuous-integration job, compare execution environments before rewriting the Clash profile. The agent may run under a different user, lack access to the local listener, use a container network namespace, or start before the proxy service is ready. A local loopback address inside a container refers to the container itself, not automatically to the host running Clash. Use the network topology and approved runner configuration to choose a reachable listener; do not expose an unauthenticated proxy on a public interface as a shortcut.
Verify the route and isolate failures systematically
A reliable troubleshooting pass changes one variable at a time. Start with Clash itself: confirm the core is running, the profile loaded successfully, the listener is enabled, and the selected policy group has a usable member. If the listener is absent or bound to a different address, application-level tests cannot succeed regardless of Git settings. If the client reports a port collision, identify the process holding that port and choose a non-conflicting value rather than repeatedly restarting services without checking ownership.
Next, verify name resolution separately from connection establishment. A hostname that resolves to an unexpected address can lead to a misleading rule match or a connection to the wrong endpoint. Compare the resolver behavior seen by the operating system, the application, and the Clash core where practical. Fake-IP or enhanced DNS settings can change how destinations appear in logs, so interpret the observed connection in the context of the client’s DNS mode. Do not infer that DNS is healthy merely because a browser can open an unrelated website.
Then establish whether the application used the local proxy. Check its own configuration, its inherited environment, and Clash’s connection list. If no matching connection appears, the problem is likely before rule selection: the application may ignore the variable, be unable to reach the listener, or use a separate network namespace. If a connection appears but is assigned to the wrong group, inspect rule order and the resolved destination. If the route is correct but the connection fails, test another approved node or policy choice and review the core’s error details before modifying application credentials.
Pay attention to the difference between authentication errors and transport errors. Git can reach a server and still fail because the account lacks repository access, an SSH key is missing, a token has expired, or a credential helper returned stale data. Homebrew can reach a service and still reject an operation because of a repository configuration or local permissions problem. A proxy timeout, connection refusal, TLS error, HTTP authorization response, and SSH public-key rejection are not interchangeable symptoms. Preserve the exact error and timestamp so you can correlate it with the connection log.
After a fix, repeat the original failing operation and at least one neighboring workflow. Confirm that Git HTTPS, Git SSH, Homebrew metadata, and a representative archive download follow the intended policies. Also verify that private repositories, internal mirrors, and ordinary direct traffic still behave as required. Remove temporary environment variables or diagnostic SSH entries when testing is complete, and document any lasting project or device configuration so teammates do not inherit an unexplained proxy setting.
Developer-focused proxy tools vary in how clearly they expose listeners, rules, and live connections. A bare terminal export is lightweight, but it leaves route visibility fragmented across individual applications; a single application-specific proxy can also miss subprocesses and SSH traffic. For a workflow spanning Git, SSH, and Homebrew, Clash V.CORE provides a practical place to manage the local proxy, inspect matching connections, and expand to TUN capture only when the use case requires it. If you want to test that workflow on your own permitted network, visit the Clash V.CORE download page.