Windows 和 WSL 先怎么分？

在 PowerShell 测：

curl.exe -I -L https://github.com --connect-timeout 10
Get-ChildItem Env:*proxy*
git config --global --get http.proxy
git config --global --get https.proxy

再进 WSL 测：

curl -I -L https://github.com --connect-timeout 10 -m 20
env | grep -i '_proxy'
git config --global --get http.proxy

Microsoft 的 WSL 文档单独说明了 WSL 网络模型。实际排查时，把 Windows 成功和 WSL 成功当成两件事；Windows 浏览器能打开，不代表 WSL 里的 npm install、git clone 或 docker build 都能走同一路径。

Git for Windows 和 WSL Git 怎么设？

Git for Windows：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --unset http.proxy
git config --global --unset https.proxy

WSL Git：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --unset http.proxy
git config --global --unset https.proxy

两边命令看起来一样，但写入的是不同 home。HTTPS remote 还要看 credential helper；SSH remote 要看 key、known_hosts 和 GitHub 的认证要求。GitHub 文档也明确区分浏览器、命令行、API、Actions 等认证方式。

WSL 的代理变量怎么写？

临时排查：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,.local
curl -I -L https://registry.npmjs.org/ --connect-timeout 10 -m 20

如果代理服务跑在 Windows 主机，WSL 里 127.0.0.1 是否可用取决于网络模式和版本。不要盲目复制 Mac 教程。长期配置前，确认重启 WSL 后仍然可用：

wsl --shutdown

Docker Desktop 和 Cursor 怎么看？

Docker Desktop 的代理在 Desktop 设置里配，不要把 Desktop 问题写进 Linux daemon.json。验证：

docker info
docker pull hello-world
docker run --rm alpine wget -S -O- https://github.com

这里也要分三层：Docker CLI 能不能连 daemon，daemon 能不能拉镜像，容器内部能不能访问外部服务。

Cursor 则先拆成：登录、扩展市场、Git 操作、Terminal 命令、项目依赖安装。Cursor Terminal 里的网络结果可能继承 shell，也可能和 GUI 网络不同。先记录在哪个子功能失败，再决定改系统、Git、WSL 还是 npm。

团队和安全限制怎么定？

团队仓库里只应有 .npmrc 的 registry scope、Dockerfile、lockfile、README 中的检查说明。不要提交个人代理地址、端口、认证 token、公司内网域名。Windows 新人入组时，给他一张检查表：PowerShell、WSL、Git、Docker、Cursor 各跑一条命令，把输出贴回任务单。

如果你在 Windows + WSL 里同时处理 GitHub、Docker、Cloudflare 和远程团队工具，网络路径不稳定会让每层问题互相遮挡。可以准备独立开发者出海稳定专线作为统一工作网络，但仍要分别配置和验证每个工具。

相关阅读

长尾问题怎么落到工程排查？

开发者搜索经常是故障式长尾，比如「GitHub clone 很慢」「Docker pull 超时」「npm install 卡住」「Stripe 后台打不开」「Cloudflare 登录验证」。正文把它们落到 DNS、代理变量、认证、CI runner、浏览器会话和团队权限上。

中文长尾说法工程化排查项团队记录字段
GitHub clone 慢DNS、HTTPS、SSH、仓库体积协议、耗时、错误日志
Docker pull 超时registry、镜像层、代理变量镜像名、runner、出口网络
npm / pnpm 卡住registry、lockfile、缓存、代理包管理器、版本、失败阶段
Stripe / Cloudflare 验证设备、浏览器、IP、2FA登录设备、角色、时间