受限网络下的服务部署

背景与约束

在中国大陆阿里云 ECS 上运行个人使用的 CLIProxyAPI、管理面板和 Mihomo，面对几个同时存在的限制：上游网络不稳定、首次镜像拉取困难、没有域名，以及不希望管理入口直接暴露到公网。

Linux 代理配置与 CPA 部署是这条实践线上的两个阶段，因此合并为一个案例。它们的原始操作记录仍然独立保留。

我的工作

我的工作是选择部署架构、集成已有服务、处理访问与出站路径，以及记录冷启动和运维问题。CLIProxyAPI、CPA Manager Plus 与 Mihomo 都是现有第三方项目，本案例不将它们列为我开发的产品。

关键判断

个人访问使用 SSH 隧道

只有本人使用时，公网域名、证书和反向代理会引入额外维护。方案采用 SSH LocalForward：服务端口显式绑定回环地址，本地客户端通过隧道访问。

这使公网入站可以收敛到 SSH，但依赖本机隧道正常工作，也不适合直接作为多人共享服务的访问方式。

将内部通信与上游出站分开

管理面板通过容器内网访问 API；只有需要访问模型上游的请求经过 Mihomo。这样，管理访问和容器健康检查不必依赖代理出口。

使用 SOCKS 代理时也需要考虑 DNS 解析的位置。原文记录了 socks5h 的选择，以及出口检查与节点故障时的处理方式。

冷启动避免循环依赖

Mihomo 自己也需要镜像，不能先假定代理已启动，再依赖它拉取所有镜像。部署先准备固定版本镜像，必要时离线导入；验证出口后再启动依赖上游访问的服务。

排障区分安装、网络与应用问题

Docker 安装完成不等于镜像仓库可达；代理节点可用也不等于目标服务可用。验证按层次进行：本地服务状态、端口转发、出口地址、目标应用响应。

已记录的结果

2026 年 7 月的复盘记录了回环地址监听、SSH 隧道、容器服务拆分、离线镜像和健康检查流程。进一步的本地控制使用 Automator 与 SwiftBar，便于检查和管理隧道。

这些是当时的部署结果与操作记录，不是对服务器当前在线状态或可用性的承诺。完整配置与具体排障过程见下方原文。

局限与后续改进

SSH 隧道和单机部署适合当前的个人使用边界。多人访问、备份恢复、持续监控和升级回滚都需要额外设计。

这个案例中更有复用价值的是判断顺序：先明确使用者与暴露面，再选择入口，最后逐层验证访问和出站链路。