IDEAS · SIGNALS · BUILDS
2026年4月13日星期一
DRAFTREVIEWLIVE
乔氪智造Ideas, Signals, Builds.
ZHEN
DraftReviewPublishedArchived
文章LEGENDARY+30 XP

从零搭建自用代理：一次 Agent 驱动的全栈网络工程实战

三台 VPS、一个 Cloudflare Worker、全程 AI Agent 协作

从买第一台 VPS 到稳定出海的完整记录。经历 IP 被封、Worker 限速、协议被识别等一系列问题，最终形成 AWS Lightsail + Vultr + CF Worker 的三层容灾架构。全程使用 AI Agent 协作完成代码编写、问题排查和架构设计。

#agent#infra#cloudflare#proxy#vps#devops
By Joker2026/04/1215 min

一、为什么要自建

先说结论：不推荐大多数人自建。买个靠谱的服务，一年一两百块，省心省力。自建适合这几类人：

  • 对隐私有洁癖，不想把流量交给别人
  • 想学网络和服务器运维
  • 有特殊需求（固定 IP、自定义规则、低延迟）
  • 折腾本身就是乐趣

我属于最后一种。用了几年商业服务，虽然稳定，但总觉得不够透明——流量走了哪里、日志存不存、哪天跑路了怎么办。于是决定自己搭一套。

整个过程全程使用 AI Agent 协作——从架构设计、代码编写、问题排查到运维监控，Agent 在每个环节都深度参与。这不是一个人闷头折腾的故事，而是人和 AI 协作解决真实工程问题的实战记录。

结果发现，这条路远比想象的曲折。

二、第一台 VPS：搬瓦工

选搬瓦工的理由

搬瓦工（BandwagonHost）在中文社区名气大，最吸引人的是它的 CN2 GIA 线路——中国电信的优质回国线路，延迟低、丢包少。选了日本大阪机房。

搭建过程

在 VPS 上装了 xray，配置 VLESS + Reality 协议。Reality 号称可以伪装成正常 HTTPS 流量，抗检测能力强。

# 安装 xray
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# 生成 Reality 密钥对
xray x25519

Reality 的服务端配置：

{
  "inbounds": [{
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [{ "id": "your-uuid", "flow": "xtls-rprx-vision" }],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "dest": "www.amazon.co.jp:443",
        "serverNames": ["www.amazon.co.jp"],
        "privateKey": "your-private-key",
        "shortIds": ["abcdef"]
      }
    }
  }]
}

结果：IP 被 GFW 封了

FATAL — 运行了不到两周，IP 直接被 GFW 封锁。从国内 ping 不通，SSH 连不上，所有代理协议全部失效。

GFW 通过**深度包检测（DPI）**识别出代理流量特征，直接把 IP 加入黑名单。Reality 协议虽然号称抗检测，但 GFW 的 DPI 能力在持续升级，TLS 握手阶段的一些细微特征还是会被捕获。

更坑的是搬瓦工的策略：IP 被封后不能退款，不能换机房，只能等 GFW 自己解封（通常 1-4 周，前提是停掉所有代理服务）。

教训：不要把鸡蛋放在一个篮子里。一台 VPS 被封，你就完全失联了。必须有备用方案。

三、紧急补位：Vultr Tokyo

为什么选 Vultr

Vultr 按小时计费，$5/月起步，最大的优势是可以随时销毁重建——IP 被封了就换一台，几分钟搞定。

搭建过程

直接上 Hysteria2 + xray 双协议。Hysteria2 基于 QUIC（UDP），xray 走 TCP，双保险。

# 安装 Hysteria2
bash <(curl -fsSL https://get.hy2.sh/)

# 生成自签证书
openssl req -x509 -nodes -newkey ec:<(openssl ecparam -name prime256v1) \
  -keyout /etc/hysteria/server.key \
  -out /etc/hysteria/server.crt \
  -subj "/CN=www.bing.com" -days 3650

# 启动
systemctl enable --now hysteria-server

结果：能用，但是慢

指标数值评价
延迟260ms不可接受
Google 搜索~1.0s能用但卡
YouTube 1080p偶尔缓冲勉强

关键发现：速度差距是线路问题，不是协议问题。同样是东京机房，不同云厂商的国际出口线路差异巨大。后来测试发现 AWS Tokyo 只有 44ms，同一个城市，延迟差了 6 倍。

四、Cloudflare Worker 中转

既然直连不理想，那走 CDN 中转呢？Cloudflare 在全球有 300+ 节点，中国用户连 CF 的延迟通常在 30-50ms。如果能把代理流量伪装成普通 HTTPS 请求，通过 CF CDN 中转到 VPS，理论上既能降低延迟，又能隐藏 VPS 的真实 IP。

架构

mihomo-party :7890 HTTPS Cloudflare CDN + Worker VLESS over WS TCP VPS (xray) VLESS Server google.com youtube.com Client CDN (30-50ms) Tokyo Target

原理：Cloudflare Worker 处理 WebSocket 连接。客户端发起 VLESS over WebSocket 请求到 CF CDN，Worker 通过 cloudflare:sockets API 连接到后端 VPS 的 xray，做透明中转。

坑 1：workers.dev 在中国被封

CF Worker 默认分配 xxx.workers.dev 域名。部署完一测——打不开。

原因：GFW 在 SNI 层面封锁了整个 workers.dev 域名。TLS 握手时 ClientHello 中的 SNI 包含 workers.dev，直接被重置连接。

解决方案：买一个自定义域名，绑定到 Worker。

# wrangler.toml
[routes]
pattern = "your-domain.com"
custom_domain = true

SNI 变成自定义域名，GFW 不会封一个普通域名。

坑 2：Worker 被 Cloudflare 限速（最离谱）

调试阶段频繁 wrangler deploy、删除、重建，触发了 CF 的内部限速。Worker 开始返回 HTTP 1101 或 522 错误。

最诡异的是：等了一整夜都没恢复。即使代码替换成最小的 hello world，同一个 Worker 名称依然报错。

// 最小测试代码 -- 在被限速的 Worker 名称下依然返回 1101
export default {
  async fetch() {
    return new Response("hello");
  }
};

经过大量排查发现：

CF 的限速是针对特定 Worker 名称的，不是账户级别的！ 同一个账户下新建一个不同名称的 Worker，完全正常。解决方案：改 wrangler.toml 的 name，重新部署，删掉旧 Worker。

坑 3：免费套餐 CPU 限制（10ms/请求）

CF Worker 免费套餐每个请求只有 10ms CPU 时间。

我最初把管理面板的 HTML（约 37KB）在 Worker 里动态拼接，400 多行 push() 调用，直接超时。更隐蔽的问题：单行超过 6000 字符的字符串会导致 V8 引擎崩溃。

解决方案：HTML 预构建，存入 KV。

// worker.js -- 从 KV 读取 HTML，CPU 时间 < 1ms
if (path === '/admin') {
  const html = await env.CONFIG.get("ADMIN_HTML");
  return new Response(html, {
    headers: { "Content-Type": "text/html;charset=utf-8" }
  });
}

坑 4：Vultr API 被 CF 屏蔽

想在 Worker 里调 Vultr API 查看服务器状态，结果 CF Worker 的出站 IP 被 Vultr 防火墙直接 403 了。太多人用 Worker 做恶意请求，Vultr 把 CF 的 IP 段拉黑了。

中转方案评价

指标数值评价
延迟~50ms不错
Google 搜索~1.5s慢
稳定性受 Worker 限速影响不可靠
流量协议WebSocket，无 UDP有限

CF Worker 最终定位为兜底方案：当直连节点全挂的时候，至少还有一条路能用。

五、AWS Lightsail：终于找到正解

延迟实测

在踩了一圈坑之后，做了一轮系统的延迟测试：

云厂商机房延迟月费
AWS LightsailTokyo44ms$5
Cloudflare CDNAnycast39ms免费
LinodeTokyo43ms$5
搬瓦工 CN2 GIAOsaka~60-80ms$$
VultrTokyo260ms$5

VPS 的网络体验，90% 取决于线路，10% 取决于协议。选对厂商比选对协议重要一百倍。

AWS Lightsail $5/月套餐：0.5GB RAM、2 vCPU、20GB SSD、1TB 流量。

搭建

# 安装 Hysteria2
bash <(curl -fsSL https://get.hy2.sh/)

# 生成自签证书
openssl req -x509 -nodes -newkey ec:<(openssl ecparam -name prime256v1) \
  -keyout /etc/hysteria/server.key \
  -out /etc/hysteria/server.crt \
  -subj "/CN=www.bing.com" -days 3650

# 关键！调整内核 UDP 缓冲区
echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
echo "net.core.wmem_max=16777216" >> /etc/sysctl.conf
sysctl -p

# 启动
systemctl enable --now hysteria-server

注意：Lightsail 上的 AlmaLinux 9 没有 firewalld，端口要通过 AWS 自己的防火墙管理：

aws lightsail open-instance-public-ports \
  --instance-name "your-instance" \
  --port-info fromPort=443,toPort=443,protocol=UDP

效果

指标数值vs Vultr
延迟44ms快 6x
Google 搜索0.32s快 3x
YouTube 4K流畅质的飞跃

终于。Google 搜索 0.32 秒，甚至比之前用的商业 VPN（0.36s）还快。

六、协议选择：为什么是 Hysteria2

协议传输层伪装方式结果
VLESS + RealityTCPTLS 指纹伪装被 GFW DPI 识别
VLESS + WS + TLSTCP (WebSocket)正常 HTTPS可用但慢
Hysteria2UDP (QUIC)标准 HTTP/3最快，稳定

Hysteria2 基于 QUIC 协议——和 Google、Cloudflare 的 HTTP/3 用的是同一套协议栈。GFW 很难区分 Hysteria2 流量和正常的 HTTP/3 流量。

QUIC 的另一个好处是多路复用和 0-RTT 连接。TCP 需要三次握手 + TLS 握手（2 个 RTT），QUIC 可以在 1 个甚至 0 个 RTT 内完成。44ms 延迟下，每次新连接节省约 88ms。

关键调优：UDP 缓冲区

# 必须设置！默认 UDP 缓冲区太小，QUIC 吞吐量上不去
sysctl -w net.core.rmem_max=16777216   # 16MB 接收
sysctl -w net.core.wmem_max=16777216   # 16MB 发送

不改这个，下载速度可能只有理论值的十分之一。

七、自建订阅系统

多台 VPS + 多种协议，手动维护客户端配置太麻烦。用 Cloudflare Worker 写了一个订阅分发系统：客户端只需导入一个 URL，所有节点信息自动下发。

Worker 暴露两个端点：

  • /clash?token=xxx — 返回 Clash/mihomo 格式的 YAML 配置
  • /base64?token=xxx — 返回 Base64 编码的 VLESS 链接

VPS 的 IP 地址存在 KV 里，动态读取。IP 变了只需更新 KV，不用重新部署。

// 订阅入口
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const token = url.searchParams.get("token");
    if (token !== SECRET_TOKEN)
      return new Response("Not Found", { status: 404 });

    // 从 KV 动态获取 VPS IP
    const awsIP = await env.CONFIG.get("AWS_IP");
    const vultrIP = await env.CONFIG.get("VULTR_IP");

    if (url.pathname === "/clash")
      return generateClashYAML(awsIP, vultrIP);
    if (url.pathname === "/base64")
      return generateBase64Links(awsIP, vultrIP);
  }
};

分流规则

订阅配置内置完整的分流规则，基于社区规则集（Loyalsoldier、blackmatrix7）：

  • AI 服务（ChatGPT、Claude、Gemini）→ 走代理
  • 流媒体（YouTube、Netflix、Spotify）→ 走代理
  • 社交/开发（Telegram、Twitter、GitHub）→ 走代理
  • 国内网站（微信、淘宝、B站）→ 直连
  • 微软/苹果 → 默认直连，可手动切换
rule-providers:
  OpenAI:
    type: http
    behavior: classical
    url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/OpenAI/OpenAI.yaml"
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,OpenAI,AI服务
  - RULE-SET,YouTube,流媒体
  - RULE-SET,Google,代理
  - RULE-SET,direct-domain,DIRECT
  - MATCH,兜底

八、管理面板与监控

三域名架构

CF Worker vps.example.com 订阅分发 VLESS WS 中转 管理 API CF Pages panel.example.com 管理面板 (纯静态) 节点测试 流量监控 VPS API api.example.com:2053 系统资源监控 网络流量统计 在线用户数 WHY THREE DOMAINS? Worker 被限速 → Pages 面板正常 → VPS API 正常 三个服务完全独立，任何一个挂了不影响其他两个

为什么要分开？因为吃过亏。最初面板是 Worker 返回的 HTML，Worker 被 CF 限速后面板也跟着挂了，什么都看不到。

分离之后：

  • CF Pages：纯静态托管，不受 Worker 限速影响
  • VPS API：跑在 VPS 上的 Python 脚本，通过 CF CDN 代理，Worker 挂了也能查看状态

VPS 监控 API

在 VPS 上跑一个轻量 Python HTTP 服务：

# /opt/vps-api/api.py
from http.server import HTTPServer, BaseHTTPRequestHandler
import json

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == '/status':
            data = {
                'cpu': get_cpu_usage(),
                'memory': get_memory(),
                'disk': get_disk(),
                'network': get_network_stats(),
                'hysteria2_users': get_hy2_online(),
            }
            self.send_json(data)

# 用 systemd 管理，开机自启
HTTPServer(('0.0.0.0', 2053), Handler).serve_forever()

通过 CF A 记录（proxied 模式）代理到 VPS 端口，VPS 真实 IP 不暴露。

面板功能

管理面板是单 HTML 文件，部署在 CF Pages：

  • AWS 实例管理：查看实例状态、带宽用量
  • 节点测试：一键检测各节点连通性和延迟
  • 订阅日志：记录每次订阅拉取的时间、IP、UA
  • VPS 监控：CPU、内存、磁盘、网络实时数据
  • CF IP 管理：自定义 CDN 中转使用的 CF 优选 IP

九、最终架构与成本

架构总览

Client (mihomo-party) AWS Lightsail Hysteria2 直连 44ms | 0.32s ★ Vultr Tokyo Hysteria2 备用 260ms | 1.0s CF Worker VLESS WS 中转 ~50ms | 1.5s PRIMARY BACKUP FALLBACK FAILOVER STRATEGY AWS 正常 → 走 AWS | AWS 故障 → 自动切 Vultr → 再降级 CF 中转

客户端使用 fallback 策略组：每 60 秒健康检查，全程自动切换，对用户透明。

月度成本

项目费用
AWS Lightsail Tokyo（主力）$5/月
Vultr Tokyo（备用）$5/月
搬瓦工 CN2 GIA（IP 封锁中）~$5/月（已付年费）
Cloudflare Worker + Pages + KV$0（免费套餐）
域名（Namesilo）~$0.4/月（$5/年）
实际月支出~$10.4/月

搬瓦工 IP 解封后 Vultr 可以停掉，降到 ~$5.4/月，约 ¥38。

十、踩坑大全与经验总结

时间线

  • Week 1 — 搬瓦工 IP 被 GFW 封锁。Reality 直连不到两周被识别。
  • Week 2 — Vultr 紧急补位。能用但延迟 260ms，确认「线路 > 协议」。
  • Week 2-3 — CF Worker 中转踩坑。workers.dev 被封 → Worker 限速 → CPU 超限，一个坑接一个坑。
  • Week 3 — AWS Lightsail 上线。44ms 延迟，0.32s Google 搜索。
  • Week 4 — 管理系统完善。三域名架构、面板、监控、订阅全部搭完。

六条关键经验

#1 选对线路比选对协议重要 100 倍

同一个城市的不同云厂商，延迟可以差 6 倍。先做延迟测试，再买 VPS。

#2 一定要有备用方案

IP 被封、Worker 被限速、协议被识别——任何单点都可能出问题。至少准备两条独立路径。

#3 Cloudflare 免费套餐的限制比你想的多

10ms CPU 限制、10 万请求/天、出站 IP 可能被拒绝、workers.dev 在中国被封。免费的东西总有代价。

#4 服务之间要解耦

监控面板不要依赖代理 Worker，VPS API 不要依赖 CDN Worker。任何服务挂了，你都应该还能看到发生了什么。

#5 不要在一台 Mac 上同时跑两个代理客户端

不同代理客户端会争夺系统代理设置。一个设成 7890，另一个设成 1087，互相覆盖，结果哪个都不通。

#6 Hysteria2 调优就一件事：UDP 缓冲区

net.core.rmem_max=16777216 和 net.core.wmem_max=16777216。不改这个，速度可能只有理论值的十分之一。

Agent 在这个项目中的角色

整个项目中，AI Agent 不只是「帮写代码」，而是全程深度参与：

  • 架构设计：分析各方案优劣，提出三层容灾架构
  • 问题排查：Worker 限速时系统性地测试排除，最终定位到「按名称限速」的规律
  • 代码实现：Worker 订阅系统、VLESS 中转、管理面板、监控 API 的全部代码
  • 运维支持：SSH 远程配置 VPS、调试 Hysteria2、设置防火墙和 systemd
  • 知识沉淀：将所有踩坑经验结构化记录，形成可复用的知识库

这不是一个人能在合理时间内完成的工程量。Agent 把「从零到可用」的周期压缩到了不到一个月。

工具链总结

类别 工具 用途 代理协议 Hysteria2, xray (VLESS) VPS 端代理服务 客户端 mihomo-party (Clash Meta) macOS 代理客户端 CDN/Serverless CF Worker, CF Pages, CF KV 中转、面板、存储 VPS AWS Lightsail, Vultr, 搬瓦工 代理服务器 域名 Namesilo + Cloudflare DNS 域名注册与解析 部署 Wrangler CLI CF Worker/Pages 部署 AWS API aws4fetch Worker 中签名调用 AWS API 规则 Loyalsoldier, blackmatrix7 分流规则集 OS AlmaLinux 9 VPS 系统 AI Claude (Agent) 全程协作

最后

这个项目前后折腾了快一个月。回头看，如果一开始就选 AWS Lightsail + Hysteria2，可能一天就搞完了。但正是因为走了弯路，才搞清楚了封锁的逻辑、各家云厂商的线路差异、Cloudflare 免费套餐的各种暗坑。

自建代理不是最经济的选择，但它是最透明的选择。你的流量走了哪里、被谁看到了、存了什么日志——这些问题的答案，只有你自己搭的时候才能确定。

而有了 Agent 的加持，这件事的门槛大大降低了。你不需要是网络工程师，不需要精通每一种协议的细节——你需要的是清晰的目标、解决问题的耐心、以及一个靠谱的 AI 搭档。

  • 仅供交流学习。请遵守当地法律法规，合理使用技术工具。*
QUEST COMPLETE—REWARD: +30 XP, +1 LEGENDARY ITEM
Build Progress100%