Appearance
网络代理运维与排查
网络代理的稳定性取决于整条链路，而不是单个进程。运维时要同时关注配置、凭据、证书、日志、连接数、带宽、DNS、客户端兼容和远端出口可达性。
运行维护对象
| 对象 | 维护内容 | 风险 |
|---|---|---|
| 配置 | 服务端配置、订阅模板、规则集 | 改错后批量客户端不可用 |
| 凭据 | 密码、token、UUID、订阅 URL | 泄露后被滥用 |
| 证书 | TLS 证书、私钥、续期任务 | 过期后客户端连接失败 |
| 日志 | Nginx、代理核心、Docker、systemd 日志 | 磁盘被打满或泄露敏感信息 |
| 资源 | CPU、内存、连接数、带宽、磁盘 | 高峰期不稳定 |
| 客户端 | 内核版本、订阅格式、规则语法 | 升级后字段不兼容 |
日志增长
代理服务的日志容易增长，尤其是访问日志、连接日志、容器标准输出和错误重试日志。生产环境至少要做三类限制：
Docker 日志限制
yaml
logging:
driver: json-file
options:
max-size: "20m"
max-file: "5"这能限制单个容器 JSON 日志体积，避免长时间运行后占满磁盘。
systemd journal 限制
ini
SystemMaxUse=1G
MaxRetentionSec=14day这些配置通常写在 journald 配置中，用来限制 journal 总占用和保留时间。
Nginx 日志轮转
如果入口网关使用 Nginx，访问日志和错误日志要进入 logrotate。保留周期取决于排障需要，不应无限保留。
日志里不要记录完整订阅 URL、密钥、token、敏感请求参数。需要排障时，可以临时提高日志级别，问题结束后恢复。
容量关注点
| 指标 | 说明 | 异常表现 |
|---|---|---|
| CPU | 加密、解密、TLS、压缩会消耗 CPU | 延迟升高、连接超时 |
| 内存 | 连接表、缓冲区、日志队列占用内存 | 进程被系统杀掉 |
| 连接数 | 长连接和并发请求都会占连接 | 新连接失败 |
| 带宽 | 出口网络决定实际吞吐 | 下载慢、抖动大 |
| 磁盘 | 日志和备份持续增长 | 服务异常、系统不可写 |
容量评估不要只看空闲内存和磁盘。代理服务更常见的瓶颈是带宽、连接数、CPU 加密开销和日志策略。
凭据轮换
凭据包括节点密码、UUID、订阅 URL token、管理后台账号、入口网关证书私钥等。轮换时要避免一次性让所有客户端失效。
推荐流程：
- 新增一套凭据，不立即删除旧凭据。
- 生成新订阅。
- 通知客户端更新订阅。
- 观察旧凭据连接数下降。
- 删除旧凭据。
- 保存变更记录和回滚方案。
如果协议或服务端不支持多凭据并存，就要安排维护窗口，并提前说明客户端需要更新。
证书维护
使用 TLS 入口时，证书是关键依赖。要维护：
- 证书申请方式。
- 自动续期任务。
- 续期后 reload 入口服务。
- 证书文件权限。
- 线上证书到期时间监控。
只看证书文件更新，不代表入口服务已经加载新证书。续期后应验证线上端口实际返回的证书。
版本升级
升级前先看三个兼容性：
- 客户端内核是否还支持旧订阅字段。
- 服务端协议实现是否有破坏性变更。
- 入口网关配置语法是否变化。
升级建议分层进行：先升级一个测试客户端，再升级服务端旁路节点，最后推广到生产订阅。不要同时升级客户端、服务端、规则和 DNS。
排查闭环
按层排查能减少猜测：
| 层级 | 观察点 | 常用判断 |
|---|---|---|
| 应用接入 | Clash Verge 连接页是否出现记录 | 没记录说明流量没进客户端 |
| 规则命中 | 连接记录命中的规则和策略组 | 命中错误说明 rules 或 DNS 有问题 |
| 节点连接 | 延迟测试和内核日志 | 失败说明客户端到远端有问题 |
| 入口网关 | 访问日志和错误日志 | 502/超时说明网关到后端异常 |
| 远端服务 | 认证日志、连接日志 | 认证失败说明凭据或协议不一致 |
| 出口访问 | 远端到目标的连通性 | 失败说明出口网络或目标限制 |
每次只改一个变量。比如只切换节点、只改 DNS、只改规则，避免同时修改导致无法定位原因。
常见现象
订阅能更新，但节点不可用
控制面正常，数据面异常。检查节点参数、端口、密码、TLS、SNI、传输路径、服务端进程和入口网关。
节点可用，但某个应用不走代理
先看连接页。如果没有连接记录，检查系统代理、TUN、应用自身代理设置。如果有连接记录，检查规则命中和 DNS。
全局模式可用，规则模式不可用
通常是规则或 DNS 问题。检查目标域名是否命中预期规则，是否被提前命中直连规则，是否在解析阶段丢失了域名信息。
浏览器可用，命令行不可用
命令行工具不一定读取系统代理。可以为单个命令设置：
bash
HTTPS_PROXY=http://127.0.0.1:7890 curl https://api.example.org如果有内网地址，要同时配置 NO_PROXY，避免内部服务被错误送进代理。
一段时间后服务变慢
检查连接数、CPU、带宽和日志。长连接堆积、日志写满、自动测速目标异常、DNS 失败重试都会造成服务变慢。
变更检查清单
上线或改配置前检查：
- 是否备份当前配置。
- 是否没有把真实凭据写入公开文件。
- 是否能回滚订阅。
- 是否验证服务端配置语法。
- 是否验证客户端能更新订阅。
- 是否验证一个直连目标和一个代理目标。
- 是否观察日志没有持续错误。
总结
网络代理运维的核心是分层观察。先确认流量进客户端，再确认规则命中，再确认节点连接，再确认远端出口。日志、凭据、证书和容量是长期稳定的底座，任何一项失控都会把“偶发问题”变成“系统性故障”。