Developer Proxy Setup for Git, npm, and Docker in v2rayN

1. Choose a proxy entry point

v2rayN manages the node, starts the configured core, and can expose local proxy listeners. Git, npm, pip, and Docker are separate applications; each may use its own proxy settings, inherit environment variables, or rely on Windows’ system proxy. A browser working through v2rayN does not prove that a terminal command or Docker image pull uses the same route.

For a terminal-only workflow, per-tool settings are usually easier to audit. They let you route just the package manager or Git traffic you need, without changing how every application on the computer connects. TUN mode is more convenient when a tool ignores proxy variables, uses several network processes, or needs UDP traffic, but it adds a virtual network interface and more routing variables to troubleshoot.

The port numbers above are examples, not guaranteed defaults. In v2rayN, check the listener information displayed in the main window and open Settings → Parameter settings to inspect the local port configuration. If you use an HTTP proxy listener, a typical local address might be 127.0.0.1:10809; a SOCKS listener might be 127.0.0.1:10808. Only use a listener that is enabled and shown by your running client.

2. Verify v2rayN and terminal connectivity

Before changing developer-tool settings, confirm that v2rayN is running, a usable node is selected, and the core has started without a configuration or port-binding error. Keep the initial test simple: use one listener, temporarily avoid running a second traffic-capture application, and leave routing rules unchanged. If you already use TUN mode, turn it off for this first per-tool test so that the request path is unambiguous.

1. Check the node

   Select a candidate server in the v2rayN server list and connect. A latency result alone is not proof that terminal traffic is routed; confirm that the client reports an active connection and inspect its log for startup failures.

2. Find the listener

   In the main window, note the enabled local SOCKS or HTTP port. Confirm the listener address under Settings → Parameter settings; use the exact value shown rather than assuming that the example ports in this guide match your installation.

3. Test the port

   Open PowerShell and run Test-NetConnection 127.0.0.1 -Port 10809, replacing 10809 with your HTTP listener port. A successful TCP test checks that a process accepts a local connection; it does not yet prove that the selected remote node can reach a website.

4. Test an HTTPS request

   Run curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/. Replace the port if needed. A returned HTTP status line shows that this curl request reached an HTTP response through the specified proxy; it does not prove that Git, npm, or Docker uses that proxy automatically.

Use curl.exe in PowerShell to call the Windows command-line program explicitly. In Windows PowerShell, curl may be an alias for a PowerShell web request command, whose options are different. For a SOCKS listener, use curl’s SOCKS option instead, for example curl.exe --proxy socks5h://127.0.0.1:10808 -I https://example.com/. The socks5h form asks the proxy to resolve the destination hostname; that can help distinguish local DNS behavior from proxy-side resolution.

3. Configure Git, npm, and pip

Choose either the HTTP listener or the SOCKS listener according to what the tool supports and what v2rayN actually exposes. For broad command-line compatibility, an HTTP proxy listener is often the simplest starting point. The following commands use http://127.0.0.1:10809 as an example; substitute your own address and port. These settings point to the local client, not to the remote proxy server.

Git

Set a proxy for Git’s HTTP transport with:

git config --global http.proxy http://127.0.0.1:10809
git config --global --get http.proxy

This affects repositories accessed over HTTP or HTTPS, not every Git transport. If you only want a temporary test, set the option for the current command with git -c http.proxy=http://127.0.0.1:10809 ls-remote https://example.com/repository.git, replacing the URL with a repository you are authorized to access. A failure against a placeholder or inaccessible repository says nothing about whether the proxy itself works; use curl as the independent network check. To remove the global setting later, run git config --global --unset http.proxy. Also inspect repository-level configuration and environment variables if a different proxy remains active.

npm

For npm, configure the HTTP and HTTPS proxy values explicitly:

npm config set proxy http://127.0.0.1:10809
npm config set https-proxy http://127.0.0.1:10809
npm config get proxy
npm config get https-proxy

Although the destination URL may start with https://, an HTTP proxy can carry the request using the HTTP CONNECT method. The proxy URL’s scheme describes the connection from npm to the local proxy; it does not mean that the package download is unencrypted. Avoid turning off certificate validation to get past a proxy error. If npm reports a certificate problem, check the computer’s clock, trusted certificates, and whether a corporate TLS inspection policy is involved. To remove these values, use npm config delete proxy and npm config delete https-proxy.

pip

Set pip’s proxy for the current user with:

python -m pip config set global.proxy http://127.0.0.1:10809
python -m pip config debug

Then run a normal installation or package-index query for a package you intend to use. The configuration file reported by pip config debug helps explain which value is active if a project-level setting or environment variable takes precedence. When diagnosing, compare the result with a one-command test using python -m pip --proxy http://127.0.0.1:10809 install PACKAGE_NAME, replacing PACKAGE_NAME with a real package. Remove the persistent setting with python -m pip config unset global.proxy if you no longer need it.

4. Configure Docker on Windows

Docker needs special attention because the command-line client and the Docker engine are not necessarily the same network process. When you run docker pull, the engine performs the image download. Setting HTTP_PROXY only in a PowerShell window may configure some local commands or containers, but it does not guarantee that the engine used for the pull inherits that environment.

Docker Desktop’s available proxy options can vary by version and installation mode. Use its settings interface for the engine rather than assuming that a shell-level docker command controls daemon networking. After changing the engine proxy, test a small public image pull, then inspect Docker Desktop’s troubleshooting information and engine logs if the request still fails. If you use a remote Docker context, the daemon may run on another machine; a proxy configured on your Windows computer will not automatically configure that remote engine.

For commands executed inside a container, a host-local address requires care. A container has its own network namespace, so 127.0.0.1 normally refers to that container itself. Docker Desktop provides host connectivity mechanisms, but the correct hostname and reachability depend on the environment. Verify that the container can reach the chosen host address before blaming v2rayN. For image builds, build-time proxy arguments and runtime container environment variables are also distinct; pass only the settings needed for the relevant phase, and avoid embedding secrets in image layers.

5. Diagnose failed installs and image pulls

When an operation fails, record which program produced the error, which destination it was trying to reach, and whether the local listener test still succeeds. Change one setting at a time. A browser success is not a substitute for a command-line test, and a package manager’s cached result may make a repeated command look successful without making a new network request.

Use the error stage to narrow the search. A local connection refusal points to the listener address, port, or client process. A name-resolution error suggests checking whether the application resolves locally or through the proxy, along with the current DNS and routing configuration. A timeout after the local connection succeeds may involve the selected node, remote reachability, firewall policy, or an incorrectly configured Docker engine. An HTTP authentication response can mean the proxy listener or destination requires credentials; do not paste tokens or passwords into public logs.

Environment variables are useful for short-lived tests, but they are not a universal configuration mechanism. In PowerShell, a temporary test can use $env:HTTP_PROXY="http://127.0.0.1:10809" and $env:HTTPS_PROXY="http://127.0.0.1:10809"; closing that shell removes those session values. Different programs may prefer lowercase names, their own configuration files, or a proxy setting managed by a background service. Inspect the effective configuration for each application instead of assuming that setting one variable covers every process.

TUN mode is a reasonable next step when a specific program cannot use a proxy setting or when several related processes need transparent routing. Enable it in v2rayN only after confirming that the core and node work through a local listener. Follow the TUN configuration presented by your installed client, grant any requested network permissions, and check routing and DNS behavior. Then verify one target application at a time. If TUN breaks local development services, package downloads, or access to private network addresses, review the client’s routing rules and bypass requirements before changing several system network settings.