受限网络下的技术访问：症状与选型

先做正确的诊断

"打不开"是症状，不是原因。工程师能做的第一件有价值的事，是把它归到某一类：

四类的处置方式完全不同，混在一起猜会浪费大量时间。

一套诊断命令

# 1. DNS：换不同解析器对比，结果不一致就是解析层面的问题
dig +short github.com @1.1.1.1
dig +short github.com @8.8.8.8
dig +short github.com                    # 本地/运营商 DNS
# 用 DoH 拿一个可信参照
curl -s 'https://cloudflare-dns.com/dns-query?name=github.com&type=A' \
  -H 'accept: application/dns-json' | jq -r '.Answer[].data'

# 2. TCP 可达性：先确认三次握手本身成不成
nc -zv github.com 443
# 在哪一跳消失
traceroute -T -p 443 github.com

# 3. TLS 握手：分辨是连不上还是握手被打断
curl -vI --connect-timeout 5 https://github.com 2>&1 | tail -20
openssl s_client -connect github.com:443 -servername github.com </dev/null 2>&1 | head -15

# 4. 绕过 DNS 直接测某个 IP，用来验证"是 DNS 的问题还是 IP 的问题"
curl -vI --resolve github.com:443:140.82.121.4 https://github.com

# 5. 速度与稳定性
curl -o /dev/null -w '%{speed_download}\n' https://speed.cloudflare.com/__down?bytes=10000000
nstat -az | grep -iE 'retrans|timeout'

判断树

拉不下依赖 / 打不开文档
   │
   ├─ dig 各解析器结果不一致，或返回明显不对的地址
   │     → DNS 层面：换加密 DNS（DoH/DoT），或让代理侧解析（socks5h）
   │
   ├─ nc -zv 超时、traceroute 在某跳后消失
   │     → 地址层面：这个出口到该目标不可达，需要换出口
   │
   ├─ TCP 通但 TLS 握手阶段断开
   │     → 握手阶段被打断：需要隧道把握手包裹在另一层里
   │
   └─ 都正常但极慢、重传高
         → 限速或链路质量：换线路，或先确认不是自己这端的问题（L0 那套体检）

自建还是用现成服务

给工程师的实际建议：如果需要在 CI 或服务器上稳定使用，自建—— 因为你需要固定出口 IP 和可预期的可用性。个人临时用途没必要。

VPS 选择的几个要点

• 地域：香港延迟最低（大陆访问通常几十毫秒），美西便宜、机房和线路选择多，但延迟通常 在一百多到两百毫秒。做交互式操作（SSH、Web 控制台）地域的影响比带宽大得多
• 流量与带宽：看清是"月流量配额"还是"不限量但限速"。前者用超会直接停机， 拉几个大镜像就可能触顶
• 回程线路：同一机房不同线路的体验能差好几倍，这是最容易被价格掩盖的一项
• 快照与重建：选支持快照的，配置搞坏了能回滚；同时看清换 IP 的政策（IP 被封时能不能换）

线路名词对照

报价页上那几个缩写是真正决定体验的东西：

判断线路真假不靠商家宣传，看 traceroute 的骨干跳：途经 59.43.x.x 说明走了 CN2， 只见 202.97.x.x 则是普通骨干（这个判据来自 haoel 的科学上网笔记）。

具体推荐

下面这几家按价格从高到低、稳定性也从高到低排列 —— 这两件事在这个领域基本是正相关的：

按用途对应：

• CI 或服务器上长期用（拉依赖、跑构建）→ 取前两档。这类场景断一次就是流水线红一片， 稳定性的钱值得花
• 个人日常看文档、查 issue → 第三档足够，香港线路的交互体验明显更好
• 临时验证一个想法、或者只是想练一遍部署 → 最后一档，用完就删

# 在 VPS 上装 mtr，往大陆三网各测一个地址
mtr -r -c 20 202.96.209.133      # 电信（上海）
mtr -r -c 20 210.22.84.3         # 联通（上海）
mtr -r -c 20 211.136.112.50      # 移动（上海）

# 看骨干跳里有没有 59.43（CN2）
mtr -r -c 20 202.96.209.133 | grep -E '59\.43|202\.97'

服务端的基础配置

# 1. BBR：长肥链路上收益最直接（L0 讲过原因）
cat >> /etc/sysctl.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl -p
sysctl net.ipv4.tcp_congestion_control      # 确认生效

# 2. 域名 + 真实证书（自签会立刻暴露）
certbot certonly --standalone -d proxy.example.com
# 续期交给 cron / systemd timer

# 3. 服务本体：用 gost 这类工具跑在 TLS/HTTP2 之上（见 gost 那一节）

三条纪律：用真实域名和证书、加认证、只开必要端口。 上一节说过，不加认证的代理挂公网上几小时就会被扫到滥用。

开发者场景：让各个工具走代理

假设本地代理是 127.0.0.1:1080（SOCKS5）和 127.0.0.1:8080（HTTP）。

# 通用环境变量（记得大小写都设，NO_PROXY 写全）
export http_proxy=http://127.0.0.1:8080  HTTP_PROXY=$http_proxy
export https_proxy=$http_proxy           HTTPS_PROXY=$http_proxy
export all_proxy=socks5h://127.0.0.1:1080
export no_proxy="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal,.svc,.cluster.local"

一个方便的开关（思路同样出自上面那份笔记）：

proxy()   { export http_proxy=http://127.0.0.1:8080 https_proxy=$http_proxy; echo "proxy on"; }
unproxy() { unset http_proxy https_proxy; echo "proxy off"; }
with_proxy() { http_proxy=http://127.0.0.1:8080 https_proxy=http://127.0.0.1:8080 "$@"; }
# 用法：with_proxy curl -I https://example.com

各工具的独立配置：

# Git（HTTPS 协议）
git config --global http.proxy socks5h://127.0.0.1:1080
# 只给某个域名走代理，避免影响内网仓库
git config --global http.https://github.com/.proxy socks5h://127.0.0.1:1080

# Git（SSH 协议）—— ssh 不认环境变量，写进 ~/.ssh/config
Host github.com
  User git
  ProxyCommand nc -x 127.0.0.1:1080 %h %p
  # 或者 ProxyCommand socat - SOCKS4A:127.0.0.1:%h:%p,socksport=1080

# Docker daemon 是系统服务，环境变量对它无效
# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:8080"
Environment="HTTPS_PROXY=http://127.0.0.1:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.internal,10.0.0.0/8"

systemctl daemon-reload && systemctl restart docker

# apt
# /etc/apt/apt.conf.d/95proxy
Acquire::http::Proxy "http://127.0.0.1:8080";
Acquire::https::Proxy "http://127.0.0.1:8080";

用途与边界

检查点

这节课的落点

• 先诊断再动手：分清 DNS 层面 / 地址不可达 / 握手被打断 / 限速 四类
• curl --resolve 是性价比最高的一条命令，一步把 DNS 与连接问题分开
• 开发者场景优先用镜像源：Go/pip/npm/cargo/容器镜像都有成熟方案，比隧道更稳
• 需要在 CI 或服务器上长期用才值得自建；个人临时用途不必
• VPS 关注地域、流量口径与回程线路（看 traceroute 的骨干跳）
• 服务端三件事：开 BBR、真实域名与证书、务必加认证
• 环境变量只对认它的程序有效；ssh/git over ssh/Docker daemon/apt 各有各的配法
• 容器里的 127.0.0.1 不是宿主机；docker build 用的是 daemon 的代理
• 用途限定在技术资料访问，遵守当地法规与公司合规政策