VPS 与 anytls：自己搭一条稳定的线

先决定要不要自建

上一节的判断树如果指到"需要一条自己的出口"，第一个问题不是用什么协议，是要不要自己搭。

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

这一节按自建的路走一遍：选机器 → 选线路 → 配服务端 → 选协议。 协议这一步会落到 anytls，理由在后半段。

VPS：决定体验的是线路，不是配置

1 核 1G 就足够跑一个代理服务，CPU 和内存基本不是瓶颈。真正要看的是四件事：

• 地域：香港延迟最低（大陆访问通常几十毫秒），美西便宜、机房和线路选择多，但延迟通常 在一百多到两百毫秒。做交互式操作（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：长肥链路上收益最直接（tcp-behavior 那节讲过原因）
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，过期当天服务就断

真实证书不是"更安全一点"的选项，是必需项 —— 下一段会说清为什么。

为什么是 anytls：TLS in TLS 这个坎

现代代理协议用的都是成熟密码学，内容本身没人解得开。协议还在不停演进， 是因为要解决另一个问题：

加密流量看起来"像什么"。

即使内容不可解密，路上的设备仍然能看到这些：

其中最核心的一个叫 TLS in TLS。代理把 HTTPS 流量装进自己的 TLS 连接时：

外层 TLS 握手（你的客户端 ←→ 你的服务器）
   └─ 建立完成后，里面开始跑：
      内层 TLS 握手（浏览器 ←→ 目标网站）
         ↑ 这个握手的包长与时序模式，在外层加密后依然有迹可循

问题在于握手是有固定形状的：ClientHello 一般偏小、ServerHello 加证书偏大、 后续几个包大小相对固定、时序也有规律。这些特征即使被外层加密包住， 包长序列和时间间隔仍然暴露在外。

于是可以判断：这条"普通 HTTPS 连接"建立后不久，里面又发生了一次 TLS 握手 —— 而正常的 HTTPS 浏览不会这样。

anytls 正是为缓解这个指纹而设计的协议，三个手段：

第三点值得单独说：减少嵌套握手的最好办法是不要反复建立它。 连接复用既降低了延迟（省掉握手往返），也顺带减少了可观测的握手次数 —— 一举两得，这也是它被列为核心特性的原因。

# 参考实现的用法，适合本地跑一遍看协议怎么工作
./anytls-server -l 0.0.0.0:8443 -p <密码>
./anytls-client -l 127.0.0.1:1080 -s "anytls://<密码>@<服务器>:<端口>"

服务端：sing-box 的 anytls 入站

{
  "inbounds": [
    {
      "type": "anytls",
      "tag": "anytls-in",
      "listen": "::",
      "listen_port": 443,
      "users": [
        { "name": "me", "password": "<用 openssl rand -base64 16 生成>" }
      ],
      "tls": {
        "enabled": true,
        "server_name": "proxy.example.com",
        "certificate_path": "/etc/letsencrypt/live/proxy.example.com/fullchain.pem",
        "key_path": "/etc/letsencrypt/live/proxy.example.com/privkey.pem"
      }
    }
  ]
}

padding_scheme 不写就用协议的默认值，它长这样：

["stop=8", "0=30-30", "1=100-400",
 "2=400-500,c,500-1000,c,500-1000,c,500-1000,c,500-1000",
 "3=9-9,500-1000", "4=500-1000", "5=500-1000", "6=500-1000", "7=500-1000"]

读法：第 n 个数据包被填充到某个长度区间，stop=8 表示第 8 个包之后不再填充 —— 握手阶段是指纹最集中的地方，填充只需要盖住开头那几个包。c 是分片标记。 默认值是被调过的，没有具体理由不要自己改：改坏了反而制造出一个独一无二的指纹。

客户端：mihomo 的 anytls 出站

proxies:
  - name: my-vps
    type: anytls
    server: proxy.example.com
    port: 443
    password: "<和服务端一致>"
    client-fingerprint: chrome        # 伪装 TLS 指纹，别留默认值
    sni: proxy.example.com
    alpn: [h2, http/1.1]
    skip-cert-verify: false           # ← 生产必须 false
    udp: true
    # 连接复用的三个旋钮，默认值适用于绝大多数场景
    idle-session-check-interval: 30   # 多久检查一次空闲会话
    idle-session-timeout: 30          # 空闲超过多久就关掉
    min-idle-session: 0               # 检查时至少保留几条空闲会话

三个 session 参数就是上面"连接复用"那一招的实际控制面。把 min-idle-session 调到 1~2 能让首次请求省掉建连往返，代价是空闲时也维持着连接 —— 交互式使用值得， 长期挂机没必要。

抗主动探测：三件事缺一不可

被动观察之外还有主动探测：直接连你那个端口，看它怎么回应。

正常的 HTTPS 服务：返回网页，证书匹配域名
配置粗糙的代理：  返回错误、直接断开、或返回可识别的特征响应
                  ← 这本身就是特征

三件配套的事：

1. 真实域名 + 真实证书（Let's Encrypt 即可）—— 自签证书本身就是强特征
2. 端口用 443 —— 非标准端口上跑 TLS 是另一个特征
3. 端口上要有个说得过去的东西 —— 用 sing-box 的 fallback 类能力或前置一个 nginx， 把认证失败的连接转给一个真实网页，比直接断开自然得多

CDN 前置：要用就得换协议

当出口 IP 本身成为问题时（被封或被限速），可以把 CDN 挡在前面：

客户端 → CDN 边缘节点（大量正常流量共用的 IP）→ 回源到你的服务器

但这里有个必须讲清楚的限制：anytls 走不了 CDN。CDN 只代理 HTTP 语义的流量， 而 anytls 是裸 TLS 之上的私有协议，边缘节点不认。要上 CDN 就得换成 WebSocket 类传输 （VLESS + ws + tls 之类），端口也限于 80/8080/443/8443 这些标准 HTTP(S) 端口。

代价也很实在：多一跳、延迟增加、CDN 的连接数与流量可能产生费用， 而且回源 IP 仍可能被识别 —— CDN 只是遮住了直连关系。

另一类问题：原生 IP

有些服务不是"能不能连上"的问题，而是连上了但被目标站点风控： 数据中心 IP 会被识别并限制（流媒体、部分 AI 服务、部分电商）。

这与前面讲的流量特征无关，属于 IP 归属问题。常见处理是用 WARP 这类服务拿一个 "住宅属性"更强的出口：

# 代理模式：本地起一个 SOCKS5，只把需要的流量送过去
warp-cli registration new
warp-cli mode proxy
warp-cli connect
# 默认监听 127.0.0.1:40000

然后在客户端里只把特定域名分流到它，其余照常走自己的出口 —— 具体怎么写规则是下一节的事。

代价对照表

每种手段都不是免费的：

一个务实的原则：从最简单的开始，遇到具体问题再加一层。 一上来就把所有手段叠满，结果是延迟高、配置复杂、出问题难定位 —— 而多数场景根本用不到那么多。一台 CN2 GIA 的小机器 + anytls + 真实证书， 已经覆盖了绝大部分开发者的日常需要。

检查点

这节课的落点

• 要在 CI 或服务器上长期用才值得自建；个人临时用途，订阅服务更省事
• VPS 上真正稀缺的是回程线路，不是 CPU 内存。看骨干跳有没有 59.43（CN2）， 并且在 VPS 上反向 mtr、跨一个晚高峰再长租
• 服务端两项基础：开 BBR、真实域名与证书（fullchain.pem，配好自动续期）
• 协议演进不是因为加密不够强，是因为加密流量"看起来像什么"； 最核心的一个是 TLS in TLS —— 内层握手的包长与时序在外层加密后仍可识别
• anytls 的三招：灵活分包、填充、连接复用，第三招一举两得（降延迟 + 少握手）
• anytls-go 是参考实现且示例配置默认不校验中间人，生产用 sing-box / mihomo
• padding_scheme 默认值是调过的，没有理由不要改 —— 改坏了等于造了个独一无二的指纹
• skip-cert-verify 必须是 false；要打开才通说明证书链配错了，去修证书
• anytls 不能过 CDN（裸 TLS）也不能配 Reality；要 CDN 就换 WS 类传输，代价是抗指纹变弱
• "原生 IP"是另一类问题（IP 归属而非流量特征），用 WARP 做特定域名的旁路出口
• 从最简单的开始，遇到问题再加一层，叠满手段只会让延迟与排障成本一起上升