开发工具的代理设置并不总是跟随 Windows 系统代理。浏览器可能已经可以访问目标网站，但 PowerShell、Git、npm、pip 或 Docker 仍然直连；反过来，终端能下载依赖，也不代表 Docker Desktop 的后台服务使用了相同代理。要让工作流稳定，先确认 v2rayN 提供的本地代理入口，再决定由 TUN 接管流量，还是逐个配置工具。
本文面向使用 Windows 和 v2rayN 的开发者，说明 TUN 模式与按工具配置代理的差别，并演示 Git、npm、pip 和 Docker 的设置与验证。示例中的本地地址和端口仅用于说明写法；请先在 v2rayN 中核对实际监听端口，再复制命令。文章也介绍代理变量继承、凭据保护和常见故障的定位顺序。
一、选择 TUN 模式还是工具代理
v2rayN 管理代理节点并启动内核；Git、npm、pip 和 Docker 则是各自独立的应用。它们是否经过代理，取决于应用有没有读取代理环境变量或自身配置，以及请求是否被 TUN 接管。只打开 Windows 系统代理，不能保证所有命令行程序和后台服务都会使用它。
推荐方案：先按工具配置，再按需启用 TUN
按工具配置
- 只让 Git、npm 或 pip 使用代理
- 容易区分工具配置与系统网络问题
- 适合固定开发环境和可复现脚本
使用 TUN 模式
- 让更多未提供代理选项的程序进入代理链路
- 需要检查虚拟网卡、路由和 DNS 状态
- 适合需要统一接管流量的桌面环境
建议先用一个工具验证本地代理入口；确认有效后，再决定是否需要 TUN。不要同时改动多个网络层设置来排查同一个问题。
按工具配置的优点是范围明确。例如只给 Git 设置代理，不会因此改变浏览器或其他程序的连接方式；缺点是新工具、子进程或后台服务可能有自己的配置入口。TUN 可以覆盖部分不读取代理环境变量的程序，但并不等于所有流量必然成功：路由、DNS、权限、虚拟网卡状态以及目标应用的网络实现都会产生影响。
- 先查入口：在 v2rayN 主界面或参数设置中确认本机 SOCKS、HTTP 或混合代理监听地址与端口。不同版本、配置和核心可能使用不同端口。
- 再选范围：仅需处理几个开发工具时，从工具级代理开始；需要覆盖更多应用时，再测试 TUN。
- 区分本地与远端：工具代理地址应指向本机回环地址，例如
127.0.0.1，而不是订阅节点的远端服务器地址。 - 保留回退路径：记录原有工具配置，验证完成后再清理临时环境变量或旧代理地址。
二、确认 v2rayN 的本地代理入口
开始配置开发工具前，先让 v2rayN 连接一个可用节点，并确认内核已启动。打开客户端的运行日志，检查是否有配置解析失败或本地端口占用提示。系统代理开关、节点连接状态和本地监听端口是不同事项：节点可连接，不代表目标工具已经连接到本地入口。
以下命令把 10808 作为示例端口，不能据此断定它就是当前电脑的实际端口。若设置中显示其他端口，应把命令里的端口统一替换。还要确认监听协议：HTTP 代理地址应使用 http://；SOCKS 入口则按客户端和工具支持情况使用相应的 SOCKS URL。把端口写对但协议写错，同样可能连接失败。
可在 PowerShell 中检查示例端口是否正在监听：
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue如果命令没有输出，不一定说明节点故障；更常见的原因是当前监听端口不是示例值、入口尚未启用，或核心未正常运行。也可以在 v2rayN 的参数设置中核对端口，再用 Test-NetConnection 127.0.0.1 -Port 10808 检查本机 TCP 端口连通性。这个检查只测试本地监听，不能证明代理出口能够访问目标站点。
三、为 PowerShell、Git、npm 和 pip 配置代理
临时环境变量适合当前终端会话：在 PowerShell 窗口中设置后，该窗口启动的子进程通常可以继承变量；关闭窗口后设置即消失。下面以本机 HTTP 代理端口 10808 为例。请先确认该端口确实提供 HTTP 代理，再执行：
$proxy = "http://127.0.0.1:10808"
$env:HTTP_PROXY = $proxy
$env:HTTPS_PROXY = $proxy
$env:NO_PROXY = "localhost,127.0.0.1,::1"HTTPS 请求使用 HTTPS_PROXY 时，代理 URL 仍经常写成 http://，因为应用通过 HTTP CONNECT 隧道建立到 HTTPS 目标的连接；这不表示目标网站改用明文 HTTP。工具对环境变量大小写的兼容性不完全相同，若某个程序仍不读取变量，应使用它自己的代理设置。
-
设置会话变量
在需要运行构建或安装命令的 PowerShell 窗口中设置
HTTP_PROXY、HTTPS_PROXY和本地回环地址的NO_PROXY。 -
配置 Git
对 Git 使用 HTTP 代理示例：
git config --global http.proxy http://127.0.0.1:10808。查看当前值用git config --global --get http.proxy；移除这项配置用git config --global --unset http.proxy。 -
配置 npm
执行
npm config set proxy http://127.0.0.1:10808和npm config set https-proxy http://127.0.0.1:10808。用npm config get proxy、npm config get https-proxy检查结果；不再需要时，可分别执行npm config delete proxy与npm config delete https-proxy。 -
配置 pip
对单次安装可运行
python -m pip install --proxy http://127.0.0.1:10808 包名。这种方式不会把代理地址写入所有项目的依赖文件，便于在临时网络环境中使用。
Git 的全局配置会影响当前 Windows 用户下的仓库；如果只想让一个项目使用代理，可在该仓库目录运行不带 --global 的配置命令，并在项目配置中检查是否存在代理值。Git 对 SSH 远程地址的连接不使用 http.proxy；遇到 SSH 拉取或推送问题，需要另外检查 SSH 客户端及网络路径，不能据此判断 HTTP 代理失效。
npm 除了代理还可能使用单独的 registry 地址。使用 npm config get registry 检查当前 registry；如果错误来自 registry 配置、证书或包版本，切换代理端口未必有帮助。pip 同样可能受到索引地址、证书和依赖源影响。排障时先保留原有索引配置，不要把带用户名或密码的代理 URL 写进公开仓库、脚本或终端截图。
用这些命令验证工具时，优先选择自己有权访问的目标，并结合工具返回的错误信息判断。HTTP 状态码、认证失败、名称解析失败和连接超时指向的环节不同；仅凭“安装失败”无法判断是节点、代理变量还是软件源的问题。
四、配置 Docker：区分命令行与后台服务
Docker 是最容易出现“终端有代理，拉取镜像仍失败”的工具之一。Docker 命令行会把请求交给 Docker Engine；在 Windows 上，Engine 通常由 Docker Desktop 管理，可能运行在独立的后台环境中。PowerShell 的环境变量不一定自动成为 Engine 的代理设置，因此需要检查 Docker Desktop 对代理的配置以及当前版本的实际行为。
- 先验证宿主入口：确认 v2rayN 正在运行，并已用前述方法核对本地代理端口。
- 查看 Docker Desktop：在设置中的代理相关页面检查是否使用系统代理或手动代理。界面位置会随版本变化；若配置要求填写 URL，应填写本机代理地址和实际端口。
- 重启并检查状态：保存设置后按 Docker Desktop 提示应用更改，等待 Engine 恢复运行，再执行
docker info查看客户端和服务端状态。 - 单独测试拉取：运行
docker pull加上自己有权限使用的镜像名。区分 DNS 错误、连接超时、认证失败和镜像不存在等响应。
Docker Desktop 的代理配置方式会随版本和部署方式变化，优先使用其设置界面提供的代理选项，并以界面提示为准。直接编辑 Engine 配置文件并不总能覆盖 Docker Desktop 的管理层，也可能在升级或重启后被覆盖。若构建过程需要代理，还应分别确认 Dockerfile 中的构建阶段、BuildKit 和容器运行时的网络访问要求；镜像拉取成功并不自动证明构建容器里的包管理器也配置正确。
若使用 Docker daemon 级代理配置，注意它作用于后台服务发起的请求，不等同于为宿主机上的所有终端程序设置代理。代理地址中的认证信息应限制在本机受控配置中，避免写入镜像层、版本库或构建日志。遇到公司网络、远程 Engine 或特殊虚拟网络时，本机的 127.0.0.1 对后台环境未必指向同一个代理服务，不能假设回环地址跨越虚拟机或远程主机仍然有效。
五、TUN 使用边界与故障排查
TUN 通过虚拟网络接口接收被路由到该接口的流量，由代理内核继续处理。它适合没有代理选项、或需要统一接管多类应用的场景，但开启后应确认虚拟网卡已建立、系统路由发生预期变化，且 DNS 能按当前配置解析。仅看到 TUN 开关处于开启状态，不足以证明某条 Git、npm 或 Docker 请求已经经过代理。
建议先在 v2rayN 中关闭 TUN，只保留一个入口测试，例如让 Git 使用本地 HTTP 代理并确认请求成功。之后再启用 TUN，对照同一条命令、同一网络和相同目标测试。如果启用 TUN 后问题出现，检查客户端日志、虚拟网卡状态和 DNS，而不是同时更换节点、重写工具代理配置并修改路由。一次只改变一个变量，才能看出故障由哪一层引入。
浏览器能打开，Git 仍然超时怎么办？
先查看 git config --global --get http.proxy 和当前 PowerShell 的 $env:HTTPS_PROXY，再核对代理端口是否提供 HTTP 入口。若远程地址是 SSH 格式，Git 的 HTTP 代理设置不会处理该连接。
npm 安装失败，是代理一定没连上吗？
不一定。检查 npm config get registry、代理配置和具体错误；超时、证书错误、认证失败以及找不到包对应的原因不同。不要先删除 lock 文件或随意更换 registry。
docker pull 报错，但 PowerShell 请求正常？
检查 Docker Desktop 的代理设置并确认 Engine 已应用更改。Docker daemon 与当前终端是不同的请求发起方，终端变量不保证自动传递给后台服务。
关闭 v2rayN 后，工具还保留代理吗？
Git 的全局配置和 npm 的代理配置会单独保存，关闭客户端不会自动清除它们。若不再使用，分别查询并删除相应设置；临时 PowerShell 环境变量则随终端会话结束而消失。
诊断时按由近及远的顺序检查：第一步确认客户端和内核正在运行；第二步核对本地监听端口及协议；第三步检查工具自己的代理设置或环境变量；第四步验证目标域名解析和远端连接；最后再检查 TUN、DNS、路由及 Docker Desktop 等后台组件。日志中若含订阅 URL、访问令牌、用户名或密码，应先遮盖再保存或分享。