yding-git/personal-edge-proxy

给 AI / Agent 的维护与部署说明 → AGENTS.md 如果你是从零开始，可以按这个顺序看： 如果只是想“能用”，一条 HY2 就够。 如果主要用途是 ChatGPT、Codex、Gemini、Claude 这类 AI 服务，我更推荐： 原因不是“某家一定会封号”或者“某家一定要求住宅 IP”，而是实际使用时一些 AI / SaaS 服务会受到地区可用性、数据中心 IP 信誉、出口变化、风控挑战等因素影响。把 AI 出口和廉价 VPS 的原生机房 IP 解耦，通常更容易维护，也更容易排错。 这不是规避服务条款的保证方案，也不能保证任何账号不会触发风控。 使用前仍应确认目标服务支持所在地区，并遵守对应服务条款。 这些档位不是强制逐级安装，而是帮助你判断“这一层到底解决什么问题”。 最重要的区分： 不要因为加了 REALITY 就误以为 AI 看到的出口 IP 变干净了——如果最终还是 VPS Direct，出口身份并没有变化。 最小形态： 如果 HY2 在你的网络里稳定，而且你不在意 AI 服务使用 VPS 原生出口，那么做到这里就可以停。 AI 可以继续完成服务器施工，但第一步最好由人把 SSH 公钥登录准备好。 推荐流程： 生成密钥： 默认： Linux / macOS： Windows PowerShell： 最后先由人验证： 不要把 SSH 私钥、VPS root 密码复制到聊天、Issue 或公开仓库。 本地 Agent 如果能直接调用你已经可用的 ssh / SSH Agent / /.ssh/config，就不需要知道私钥内容。 推荐结构： 这样做的价值： WARP 不是住宅 IP，也不能保证某个服务一定接受它。 它只是一个独立、方便维护的 Cloudflare 出口。 详见：docs/warp-outbound.md 如果你希望 Claude / Anthropic 长期保持同一个最终出口： 这样 HY2/REALITY 怎么切、VPS 是否迁移、WARP 是否重连，都可以与这条固定出口策略分开管理。 但要强调： 详见：docs/static-socks.md 我把它们视为入口冗余： 它们不会自动改善 VPS 的最终出口 IP。想改善出口，需要 WARP / Fixed SOCKS5 等 outbound 策略。 生产机经历过多轮实验，所以仓库 example 不是原样复制生产配置，而是： 官方参考： examples/xray-server.example.jsonc…