PackHorizon¶

代理基础设施的配置打包、校验与发布工具 — 从 Azure 同步 VM 状态，生成完整 Clash 订阅，批量测试节点，一键发布。

产品定位¶

PackHorizon 是 Dad 构建的代理配置自动化工具链，核心目标是： 1. 云资源同步 — 以 Azure VM 状态为真相源，自动修正本地配置 2. 完整配置生成 — 不只是节点列表，而是可直接导入的完整 Clash YAML 3. 批量连通性验证 — 在跳板机上测试所有节点后再发布 4. 一键订阅发布 — 推送到远程静态目录供客户端拉取

核心理念：配置不是手工真相，云资源状态才是真相源（source of truth）。

技术栈¶

层级	技术选型	说明
云资源层	Azure CLI	VM 列表、IP、状态同步
配置格式	Clash YAML	proxies + proxy-groups + rules
测试环境	跳板机	批量节点连通性验证
发布层	SCP + 静态目录	远程 Web 目录承载订阅文件
协议支持	sing-box / hysteria2 / naive	多协议代理节点
规则源	blackmatrix7	外部成熟规则集

演进时间线¶

日期范围	阶段	关键事件	详情
03-04	架构雏形	从手工检查演进为"脚本化配置校验"，确立"云上为准"原则	[[03-04-架构雏形]]
03-05	发布链路	订阅发布完整闭环：生成 → 测试 → 发布 → 可访问	[[03-05-发布链路]]
03-09	规则完整性	微软服务规则纳入，规则源切换到 blackmatrix7	[[03-09-规则完整性]]
03-10	大规模重建	5 个全球节点逐区创建，机会式部署策略确立	[[03-10-大规模重建]]
03-28	监控纳管	PackHorizon 服务器纳入统一监控，采用"保留监控但暂不处理"策略	[[03-28-监控纳管]]
04-01	运维受阻	SSH 失联 + Azure CLI 未登录，双通道不可用	[[04-01-运维受阻]]

关键时刻¶

1. "云上为准"原则确立（03-04）¶

背景：本地 profiles 目录中的 YAML 配置与 Azure 云上 VM 实际状态不一致。

Dad 决策： - 云上没有的 VM，本地配置里直接删掉 - 本地缺失但云上存在的 VM，要补回配置

影响：这奠定了 PackHorizon 的核心原则 — 配置不是手工维护，而是从云端同步。

2. "主代理写脚本，子代理跑脚本"模式（03-04）¶

问题：让子代理自己规划"获取 VM → 对比配置 → 测试连通性 → 修配置"这类多阶段任务，容易超时或中途退出。

根因：不是模型能力不足，而是任务结构错误。

关键决策： - 主代理负责规划与生成确定性脚本 - 子代理只负责执行，减少上下文漂移

技术方案：

# 本地读取 YAML，生成测试脚本
# 将配置传到跳板机
scp proxy-config.yaml <jump-host>:/tmp/
# 在跳板机执行测试
ssh <jump-host> 'bash /path/to/test-script.sh'

3. 从"节点列表"到"完整订阅"（03-05）¶

问题：生成的 YAML 只有 proxies，没有 Rules、Proxy Groups、Rule Providers，导致配置"没办法用"。

解决方案：为生成的 YAML 补充完整的分流规则、策略组、规则集。

里程碑：PackHorizon 从"节点清单生成器"升级为"完整 Clash 配置打包器"。

4. 机会式部署策略（03-10）¶

背景：Azure 资源容量与机型可用性不稳定，Standard_B1s / Standard_B2s 在部分区域无库存。

Dad 决策：不要先全量查询可用区，直接按全球分布规划后逐区试错。

原因： - Azure API 查询慢 - 先查再建反而更慢

新策略： - 先选代表性区域（日本/美国/欧洲/东南亚/南美） - 一个一个试 - 不支持就换邻近区域

实际执行： | 节点 | 区域 | 备注 | |------|------|------| | proxy-hydra | japanwest | | | proxy-mantis | westus2 | | | proxy-jaguar | northeurope | | | proxy-shark | southeastasia | | | proxy-bison | chilecentral | brazilsouth 不支持，回退到 chile |

5. 测试与发布分离（03-05）¶

问题：最初方案在跳板机上执行 scp 推送配置，但连接超时、SSH key 认证失败。

根因：跳板机没有目标服务器的私钥，发布链路设计错位。

修正方案： - 测试仍在跳板机执行 - 发布改为在本机执行 scp

架构分层： - 测试执行层：跳板机 - 发布执行层：本机 - 订阅承载层：远程 Web 目录

核心功能清单¶

配置同步¶

[x] Azure VM 列表获取
[x] IP 漂移检测与修正
[x] 密码/认证信息同步
[x] 证书策略修正（skip-cert-verify）

配置生成¶

[x] 完整 Clash YAML 输出
[x] Proxy Groups 策略组
[x] Rules 分流规则
[x] Rule Providers 规则集
[x] 外部规则源集成（blackmatrix7）

连通性验证¶

[x] 跳板机批量测试
[x] 服务存活检测
[x] 配置正确性验证（密码匹配等）
[x] 测试结果汇总

订阅发布¶

[x] SCP 推送到远程目录
[x] 原子写入（先临时文件再 rename）
[x] 发布门禁（先验证再发布）

架构决策记录¶

决策	选择	理由
配置真相源	Azure VM 状态	避免手工配置漂移
任务分工	主代理写脚本，子代理执行	减少超时和上下文漂移
测试环境	跳板机	网络环境更接近实际使用场景
发布方式	本机 SCP	跳板机没有目标服务器私钥
规则来源	外部规则源	降低维护成本，提高覆盖率
区域选择	逐区试错	Azure API 查询慢，先查再建反而更慢
VM 规格	B2ts_v2 / B2ls_v2 优先	当前可用性较好的 x86_64 规格

核心设计原则¶

云上状态优先于本地配置 — 同步而非手工维护
主代理写脚本，子代理跑脚本 — 减少自主规划带来的不稳定
测试与发布分离 — 不同环境用不同执行路径
先验证，再发布 — 不允许"先发后修"
配置输出必须是完整可用配置 — 不只是节点列表
产物写入必须原子化 — 避免发布半成品
保留监控但可忽略故障 — 资产覆盖与故障处理优先级分离

重要路径¶

# 配置文件
~/.openclaw/workspace/profiles/proxy-config.yaml

# 技能脚本
~/.openclaw/workspace/skills/proxy-check/
├── proxy-check.sh
└── SKILL.md

# 订阅发布目录
/home/resley/.openclaw/workspace/projects/memory-lane/public/

# 发布命令
scp proxy-config.yaml resley@i.dora.restry.cn:/path/to/public/

典型工作流¶

# 1. 同步 Azure VM 状态
az vm list --output table

# 2. 生成/修复配置
# 主代理根据云端状态更新本地 YAML

# 3. 传输到跳板机测试
scp proxy-config.yaml <jump-host>:/tmp/

# 4. 执行连通性测试
ssh <jump-host> 'bash /path/to/test-script.sh /tmp/proxy-config.yaml'

# 5. 验证通过后发布
scp proxy-config.yaml resley@i.dora.restry.cn:/path/to/public/

典型问题与解决方案¶

问题	根因	解决方案
节点不可用但服务未挂	IP 漂移/密码不匹配/证书策略	从云端同步真实状态
订阅文件不可用	缺少规则/策略组	补齐完整 Clash 配置
子代理超时	自主规划多阶段任务	预构建脚本，只让子代理执行
发布失败	跳板机无目标私钥	改为本机执行 SCP
区域/机型不可用	Azure 容量波动	逐区试错，动态回退
SSH 双失联	OS 不可达 + CLI 未登录	保持两条运维通道可用

项目状态¶

当前 PackHorizon 服务器 SSH 不可达，Azure CLI 未登录，处于"双失联"状态。已纳入统一监控列表，标记为 unreachable，等待后续处理。