概述
VPN/代理服务器管理是 fries-mac 最频繁的工作主题之一（602条消息），涵盖代理节点的配置文件管理、可用性检测、YAML 配置生成和 sing-box 客户端集成。用户共有约 10 个代理节点分布在不同 Azure VM 上，需要持续维护和检测。
关键事件
- 2026-03-03: 用户要求查找记忆中的代理配置文件，开始整理代理信息
- 2026-03-05: 清理过期节点和配置文件，只保留可用节点
- 2026-03-07: 收集全部 10 个代理节点，生成 YAML 配置并存入记忆
- 2026-03-10: 使用 sing-box 进行真实连接测试（不仅仅是 ping），通过访问 IP 检测网站验证代理是否生效
- 2026-03-15: 对所有节点进行全面检查，标记 ok/不可用状态；不可用节点保留记录直到 VM 被删除
- 2026-04-02: 持续维护代理节点列表，清理已删除 VM 对应的记录
- 2026-04-27: tiger 在 ottor 频道接连给两台新 Azure VM 部署 Hysteria2（hy2 / sing-box）+ 生成完整 Clash 配置：
52.175.52.1（账号 wef /!QAZ2wsx3edc，22 端口）→ Azure-HY2-1 节点20.187.147.134（luyang /HaoxinPass01!）→ 部署完连 SSH 都断了（Ping 不通），疑似 VM 死机或 NSG 状态变化，作废- 替换为
20.157.213.63（同套凭证）→ Azure-HY2-2 节点 - 端口统一 UDP/443；最终合并的 Clash 配置含
PROXIES手切组 +AUTO延迟自动选组 + 国内直连/去广告/国外代理常用 rule
经常踩的坑
sing-box服务端配置生成时 bash 命令替换吞密码 — 多次出现（04-26 cobra 起 test-postgresql 容器、04-27 tiger 部署 hy2 两次都中招）：脚本里用$(...)注入密码到 JSON config 时，遇到含特殊字符的密码会被 shell 提前求值/转义吃掉，最后写进配置的密码字段是空的。客户端连不上 → 排查很久才发现。修法：直接cat > config.json <<'EOF'heredoc（单引号防求值）或先printf %q转义后再注入，并在重启服务前grep -c password config.json校验非空。
技术要点
- 配置格式: YAML 文件，包含所有代理节点信息
- 检测方式: 使用 sing-box 实际连接 + 访问获取 IP 的网站确认代理生效
- 节点管理策略: ping 无响应但可能仍能使用的节点需通过实际连接验证
- 存储位置: 配置文件存入 Agent 记忆（LanceDB），确保后续查询可用
- Azure NSG: 部署完后必须确认入站规则放行（hy2 = UDP/443），UFW / iptables 也要放开
经验教训
- 仅靠 ping 不能判断代理可用性，必须通过 sing-box 真实连接测试
- 代理配置文件要存入长期记忆，避免每次重新查找
- 不可用节点不应立即删除，只有 VM 彻底删除后才清理对应记录
- 代理节点需要定期巡检，Azure VM 可能因费用超标被暂停
- quokka 配合
ottor-pc-cloud-bot每日 23:00 自动巡检 8 个节点（proxy-korea-tiger、proxy-singapore、proxy-hongkong、proxy-hydra、proxy-mantis、proxy-jaguar、proxy-shark、proxy-bison） - Azure 费用管控可能自动关闭 VM，需要打
CostControl: Ignore标签防止自动关机 - 部署完 hy2 后，VM 反而 SSH 断连/Ping 不通的情况 04-27 出现过一次（
20.187.147.134），底层原因不明（可能 NSG 状态切换或 VM 挂起），重要节点要换 IP 重做不要硬等
相关主题
- azure-vm-management
- ssh-server-ops
- network-debugging
- quokka — 运维一号助手，负责代理节点巡检
2026-05-04 家里 OpenWrt Mihomo 全屋透明代理诊断 + 订阅热更（ottor-laptop）
家里全屋丢包诊断：笔记本 ↔ 网关 ping 0%，网关 → 国内 DNS 0%，但 ping 1.1.1.1 100%、ping baidu.com 解析到 198.18.167.213（典型 fake-IP 段）。结论：不是物理丢包，是路由器 OpenWrt 上的 Mihomo (clash.meta) v1.19.24 配置问题。
| 现象 | 根因 |
|---|---|
| ping 域名 100% 丢、浏览器/curl 反而 OK | dns: null 但 fake-ip 段被另一层（dnsmasq / 缓存）劫持，回的 198.18.x 没人转发 |
ping 1.1.1.1 100% 丢、8.8.8.8 13% 丢 | 出站节点/规则在 Clash 这边不通或不稳 |
iptables 已经 PREROUTING -j CLASH → REDIRECT 7892 | TCP 全屋强制走 redir 透明代理，不需要再开 TUN |
订阅源 https://i.dora.restry.cn/proxy-config.yaml（256 行：6 节点 + 8 组 + 14 rule-providers + 17 rules）。热更工具链：拉远端 YAML → 只替换 proxies / proxy-groups / rule-providers / rules 四块，保留本地 mixed-port: 7890 / redir-port: 7892 / dashboard / secret: 123456 / dns fake-ip / geox-url（订阅里的 port / socks-port 不能覆盖透明代理端口）→ 备份原 config → 走 Clash API 热重载（不重启 mihomo）→ 触发健康检查自动选节点。沉淀为 skill devops/clash-router-subscription-update。
节点清单（硬编码在 proxies: 段，无 proxy-providers / 无 cron 自动更新）
7 个 Azure 自建节点：🇰🇷 proxy-korea-tiger（已挂）/ 🇸🇬 proxy-singapore (NaivePr) / 🇭🇰 proxy-hongkong (NaivePr) / 🇯🇵 proxy-hydra (Hysteria2) / 🇺🇸 proxy-mantis (West US) / 其他。订阅替换后 6 节点全 HY2/UDP/443。
TUN 不开的决定
现状 redir + iptables 已经接管了 TCP+DNS。HY2 节点是 mihomo→Azure 的 raw socket UDP/QUIC，与本机 TUN 无关。TUN 只多覆盖局域网 → 路由器这一段的 UDP（QUIC fallback TCP / 不打竞技 UDP 游戏 / 视频会议 DIRECT），收益小、引入冲突风险大 → 不开。
凭证
ssh root@192.168.1.1 / Home@here1；Clash dashboard http://192.168.1.1:9090 / secret 123456；config 路径 /etc/clash/config.yaml。