Developer Proxy Setup for Git, npm, Docker, and AI Tools

GitHub timeouts, failed npm install operations, blocked Docker image pulls, and unreliable AI coding tools can interrupt an engineer’s entire workflow. The usual mistake is to configure each application independently, copy a different proxy port into every tool, and then lose track of which setting is active. A better approach is to let v2rayN provide one stable local entry point, then connect terminals, IDEs, package managers, containers, and command-line assistants through environment variables or tool-specific settings.

Choose the local proxy entry point first

v2rayN does not normally make Git, npm, or Docker communicate directly with a remote VLESS or VMess server. Instead, v2rayN starts a local inbound listener, receives traffic from an application, and forwards that traffic through the selected node and routing rules. From the application’s point of view, the remote server is simply a local proxy address. This separation is useful because changing a node or subscription does not require rewriting every developer tool.

For command-line tools, the most convenient entry point is usually an HTTP proxy. In a typical v2rayN configuration, the HTTP listener is 127.0.0.1:10809, while the SOCKS5 listener is 127.0.0.1:10808. These numbers are common defaults rather than guaranteed values. Open v2rayN’s main window and check the current local port under “Settings” → “Parameter settings”, or inspect the active core configuration and log. A port copied from an older installation may be wrong after a profile migration.

Use the HTTP listener for tools that document a proxy URL such as http://host:port, including Git’s HTTP transport, npm, curl, and many language package managers. Use the SOCKS5 listener when a program explicitly supports SOCKS5 or when you need a general-purpose proxy interface. Do not write socks5:// in an HTTP-only field, and do not assume that a field called “HTTP proxy” can understand a SOCKS5 URL.

Set a reusable terminal proxy without changing every command

Environment variables are the most practical shared layer for terminal-based development. Many tools recognize HTTP_PROXY, HTTPS_PROXY, and NO_PROXY, while some tools also check lowercase variants. Set both cases when working across shells or scripts. For HTTPS destinations, it is common to use the HTTP proxy URL because the client sends an HTTP CONNECT request to the local proxy and then carries encrypted HTTPS traffic through that tunnel.

1. Verify v2rayN

   Start v2rayN 7.15.4 or a later compatible release, select a confirmed working node, and check “Settings” → “Parameter settings” for the active HTTP and SOCKS5 ports.

2. Test the HTTP port

   Run curl -I -x http://127.0.0.1:10809 https://registry.npmjs.org/. A response header proves that the terminal can reach the local listener and that the selected route can reach the target.

3. Export variables

   Set HTTP_PROXY and HTTPS_PROXY to the local HTTP proxy, then define NO_PROXY for loopback, local services, and private development addresses.

4. Open a new shell

   Restart the terminal or reload the shell profile so child processes inherit the variables. Check with env, PowerShell’s Get-ChildItem Env:, or the IDE’s integrated terminal.

5. Test one tool

   Run a harmless metadata request such as npm ping or git ls-remote. If it fails, inspect the exact error before adding more configuration.

Shell examples and configuration scope

On PowerShell, the following variables apply to programs started from the current terminal. They do not automatically modify every already-running IDE or background service.

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:NO_PROXY = "127.0.0.1,localhost,::1,.local"

On a POSIX-compatible shell, use the equivalent export commands:

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export NO_PROXY="127.0.0.1,localhost,::1,.local"

Keep NO_PROXY deliberately small at first. Add internal domains, a local registry hostname, or a private network range only when needed. A broad value can silently bypass the proxy and make a connection appear inconsistent. Conversely, forcing local services through v2rayN can create needless latency or prevent access to a service bound only to the host network.

Configure Git and npm with separate, reversible settings

Git and npm often fail for different reasons even when both appear to be “network problems”. Git may be using a stale global proxy, while npm may be reading a project-level configuration or an environment variable. Configure each tool intentionally and understand which setting has priority. Avoid placing credentials in a proxy URL unless the local listener genuinely requires authentication; a normal v2rayN local inbound does not need a username or password.

Git proxy settings

For Git operations over HTTP or HTTPS, configure the HTTP proxy with the local HTTP listener:

git config --global http.proxy http://127.0.0.1:10809
git config --global https.proxy http://127.0.0.1:10809
git config --global --get-regexp "http.*proxy"

The second command displays the active proxy-related entries. Test with a remote that you are authorized to access:

git ls-remote https://example.com/engineering/project.git

Replace the example address with your real remote. If Git reports a connection refusal, the local port is not listening or the port is incorrect. If it reports a timeout after connecting, inspect the selected node, routing mode, and core log. If authentication fails, do not assume the proxy is the cause: credentials, access permissions, and remote URL syntax are separate layers.

To remove a global proxy and return Git to its default behavior, use:

git config --global --unset http.proxy
git config --global --unset https.proxy

You can also apply a temporary proxy to one command with git -c http.proxy=.... This is useful when a script should not change the user’s permanent configuration. SSH-based Git remotes are different: Git’s HTTP proxy settings do not automatically proxy an SSH connection. Either use an HTTPS remote where appropriate or configure the SSH client through a separately supported SOCKS or jump-host method.

npm registry and certificate behavior

npm supports proxy settings directly. Use the HTTP listener for both HTTP and HTTPS proxy fields:

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
npm ping

Do not begin by setting strict-ssl=false. That option disables certificate verification and hides certificate or interception problems rather than fixing the route. With a local proxy forwarding encrypted traffic normally, npm should continue to validate the registry certificate. If a company-managed certificate policy or private registry is involved, follow that organization’s certificate procedure instead of weakening verification globally.

Project-specific behavior can override a global npm setting through a local .npmrc. When two projects behave differently, compare npm config list, the project directory, and inherited environment variables. Private registries may also need to remain outside the proxy:

npm config set noproxy "localhost,127.0.0.1,.local"

Remove the npm settings when finished with a temporary test:

npm config delete proxy
npm config delete https-proxy

Make Docker use the proxy at the correct process layer

Docker is frequently misunderstood because image downloads may be performed by the Docker daemon, not by the terminal process that runs docker pull. Setting HTTP_PROXY in a shell can help Docker CLI requests in some situations, but it does not necessarily configure the engine that contacts a registry. If pulls fail while curl and npm work, treat Docker as a separate service and configure its daemon or desktop engine proxy.

First confirm the basic route from the host:

curl -I -x http://127.0.0.1:10809 https://registry-1.docker.io/v2/
docker version
docker info

A registry may return an authentication-related status rather than a normal web page; that alone is not proof of failure. The important distinction is whether the request reaches the registry without a DNS timeout, connection refusal, or TLS handshake error. Next, configure the proxy in the Docker environment you actually use. For a system-managed Docker Engine, the service configuration commonly contains daemon environment variables such as:

HTTP_PROXY=http://127.0.0.1:10809
HTTPS_PROXY=http://127.0.0.1:10809
NO_PROXY=127.0.0.1,localhost,::1

The exact service-file location and restart command depend on the operating system and service manager. After changing the daemon configuration, restart the Docker service and verify the values shown by docker info or the service logs. For Docker Desktop, use its engine or resources settings rather than assuming that the host shell variables configure the embedded daemon. A desktop virtualization layer may also interpret 127.0.0.1 differently from the host: the address must be reachable from the process that runs the daemon.

This distinction matters when v2rayN listens only on the host loopback interface. If the Docker daemon runs inside a virtual machine or another isolated environment, its own 127.0.0.1 may refer to that environment, not the Windows host. In that case, use the host address that the Docker environment can reach, and expose the v2rayN listener only as broadly as necessary. Do not bind a proxy to all interfaces merely to avoid diagnosing a virtualization boundary.

Connect IDEs and AI coding tools without losing local services

Most IDE integrated terminals inherit the environment of the IDE process, not the environment of a shell opened later. If a terminal works in a standalone PowerShell window but fails inside the IDE, fully restart the IDE after setting the variables, then inspect its terminal environment. IDE extensions may have their own network settings, and language servers may run as separate child processes. Configure the smallest relevant scope: terminal variables for command-line package operations, an IDE proxy setting for extension downloads, and a tool-specific setting only when the AI coding tool does not honor standard variables.

AI coding tools commonly need access to an API endpoint, model metadata, package registries, or authentication services. Start with the same HTTP proxy variables used by Git and npm:

HTTP_PROXY=http://127.0.0.1:10809
HTTPS_PROXY=http://127.0.0.1:10809
NO_PROXY=127.0.0.1,localhost,::1,localhost:3000

Some tools use uppercase names, some use lowercase names, and some expose a dedicated “Proxy” field. Check the tool’s own documentation and diagnostic output rather than adding random variables. If the tool offers a proxy URL field, enter the URL with its scheme, for example http://127.0.0.1:10809. If it supports SOCKS5, use socks5://127.0.0.1:10808 only in that SOCKS-aware field.

Keep local development endpoints in NO_PROXY. A coding assistant may call a local test server, an internal package registry, or a local model gateway. Sending those requests through a remote node can cause authentication failures, unexpected latency, or access-control problems. Conversely, do not put a public API hostname in NO_PROXY simply because one request failed; that bypasses the intended route and can recreate the original timeout.

When diagnosing an AI tool, change one layer at a time: first test the v2rayN local port, then a simple HTTPS request, then the tool’s own endpoint, and finally the IDE integration. Record the exact hostname, port, HTTP status, and timestamp. A generic “network error” is less useful than a log showing DNS failure, proxy refusal, TLS timeout, or an HTTP authentication response.