为什么“一个出口”满足不了 AI 时代的开发者
速度快的节点用不了 Claude Code；家宽 IP 能用，却慢得像拨号。问题不在节点，而在“所有流量走同一个出口”这个前提。
阅读全文 →在 Docker、WSL 与虚拟机里优雅地使用代理
宿主机连上了，容器里的 `pip install` 还在超时？因为容器里的 127.0.0.1 不是你的电脑。
先搞清楚一件事
127.0.0.1 永远指“我自己”。在容器里，它指容器；在 WSL2 里，它指 WSL 虚拟机；在 VMware 里，它指虚拟机。所以宿主机上的 127.0.0.1:7898，在这些环境里是访问不到的。
两类需求，分开处理
| 需求 | 谁在发请求 | 怎么配 |
|---|---|---|
docker pull 镜像 | Docker 守护进程 | 守护进程的代理设置 |
容器里 pip install | 容器内的进程 | 容器的环境变量，指向宿主机 |
Docker Desktop：用 host.docker.internal
Docker Desktop 为容器提供了一个特殊主机名 host.docker.internal，指向宿主机：
docker run --rm -e HTTPS_PROXY=http://host.docker.internal:7898 python:3.13 pip download requestsLinux 原生 Docker、WSL2、虚拟机：共享代理
这些环境的请求来自私有网段的另一个地址。为了安全，CoderBoost 的本机代理默认只接受本机连接。你需要：
- 在客户端开启“共享代理”，只允许对应的私有网段；
- 为每个来宾生成独立凭据（口令只显示一次）；
- 在来宾里用
http://用户名:口令@宿主机地址:端口作为代理。
为什么要凭据？因为一旦对网段开放，同网段的其他设备也能连上来。独立凭据让你知道是谁在用，也可以随时单独撤销。
三个常见坑
- 把代理写进 Dockerfile 的 ENV：代理地址甚至口令会留在镜像层里。用
--build-arg传入。 - 忘了 NO_PROXY：容器访问内部服务（数据库、其他容器）也走了代理。设置
NO_PROXY=localhost,127.0.0.1,.internal,db。 - WSL 的宿主机地址会变：每次启动用
ip route动态取默认网关，不要写死。