把亿级上下文压缩（ranxianglei/billion-context）从笔记本搬到阿里云 ECS，难的从来不是装包，而是三件云上才有的事：实例怎么出网去够模型 API、代理该绑在哪个地址、安全组到底放行哪些端口。
装法与拓扑
代理架在编程助手与其模型 API 之间，用 acp-kernel 压缩重写 Anthropic/OpenAI 流，原则是「何时压缩、压缩什么 —— 由模型决定，而非硬截断」。放到 ECS 后链路分三段：助手或远程 agent 到本机代理，代理再到模型 API。只有中间那段可控，剩下两段就是「谁连进来」和「怎么出网」。
第一条 curl 返回 {"ok":true,"upstream":"https://api.anthropic.com"}，就说明服务活着、也知道转发到哪。
实例规格与出网
代理不做推理，只做压缩重写与流式转发，CPU 与内存都不是瓶颈，常见入门规格够用。真正要在下单前确认的是出网：安全组只管入方向，若实例既没有公网出口、也没配 NAT 网关，代理连模型 API 都够不到，日志里会直接看到上游失败。
确认出网后，再决定代理自己怎么出去。README 的开关是让代理自身出站流量走 v2rayA/clash：在配置里设 proxy，完整解析顺序见 CONFIGURATION.zh-CN.md（服务端设置 → proxy）。两个细节先记住：空字符串等于显式直连；SOCKS5 被拒绝。
安全组放行什么
代理默认只绑 127.0.0.1，只接受本机连接，这决定了最小放行策略：
- 助手与代理同机（最常见）：安全组不需要任何入方向规则，流量走回环，不出网卡。
- 只想用浏览器看代理自带的 Web UI 与 JSON API（
http://localhost:8787的仪表盘、会话列表、实时日志、配置编辑器、上游连通性测试）：优先 SSH 隧道，别把端口开到公网。 - 只有确实要让另一台机器的 agent 连进来，才放行对应端口，并把来源收窄到那台机器的固定 IP，而不是
0.0.0.0/0。
要看仪表盘，最省事的是本地端口转发，代理始终绑回环、安全组一条规则都不用加：
然后在本地打开 http://localhost:8787。
四个必须提前想清楚的坑
坑一：把端口 8787 写死在脚本或安全组里。 现象是换一种安装方式，脚本里的探活就全挂。原因是端口归属和直觉不同：bili start（手工）拥有 8787，而 lane 替你拉起的一切（原生 hook、启动器 lane）住在独立的自管端口区，从 18787 起，碰撞就 +1 跳口、每个 lane 记住自己的漂移；刻意常驻的 bili start 守护进程则默认被附着。升级重启时若旧版本还在该 lane 端口上排水，会最多等 5 秒让它释放并复用同一端口，而不是漂移（#1723），只有真正被占用的端口才跳口且会打 warn。解法是探活别写死端口号：以 curl -s http://localhost:8787/__bili/health 或 lane 自己的登记定位实际监听地址，安全组规则跟着实际端口走。
坑二：为了让远程 agent 连上，直接 --host 0.0.0.0 并把端口开给全网。 现象是很快会在公网扫描里看到它。原因是这个开关完全没有鉴权，README 明说只应在可信局域网或防火墙内使用（/__bili/ 管理端点仍仅限本机访问），启动时的 [security] 警告就是在提醒这件事。解法是能不开就不开，本机用回环加 SSH 隧道；确需远程时把来源收窄到具体 IP，并在云防火墙与主机防火墙两层都留一道。
坑三：远程 agent 连不上私网或回环上游，以为是网络问题。 现象是客户端用 /bili/<绝对URL> 指向内网上游时被拒。原因是目的地准入规则：代理自身与 link-local/metadata 地址一律拒绝；loopback 与私网目的地对本地客户端放行、对远程客户端拒绝。解法是把需要的 host 或 host:port 写进 BILI_TUNNEL_ALLOWED_HOSTS（逗号分隔），而不是关掉整条准入逻辑。
坑四：出网被上游代理挡住，或配了 SOCKS5 却不生效。 现象是本地直连模型 API 没问题，代理进程却连不上。原因是代理自身出站走 v2rayA/clash 时需显式设 proxy，而这份配置有两条容易记反的规则：空字符串表示显式直连（不是「不设置」），且 SOCKS5 被拒绝。解法是按 CONFIGURATION.zh-CN.md（服务端设置 → proxy）的解析顺序确认生效，并注意 mitm:// 与 https:// 的键 scheme 区分。
验收
健康检查通过后发一条真实消息，日志（~/.local/state/billion-context/bili.log，同时镜像 stderr）里应出现 processTurn，对话变长后出现 [acp-usage] round N input=X cached=Y (cache hit Z%) 与 compress 事件；缓存命中率健康区间是 95–97%，压缩本身代价 ≤2%。
另需说明：项目自述状态为「早期」，协议处理和压缩已通过 mock 测试（500+ 项通过），真实模型集成测试是下一里程碑。云上部署前建议先备份 ~/.dsh 配置，出问题好回滚。
总结
在阿里云 ECS 上跑这个代理，关键只有三件事：出网要通、端口不要写死、暴露面只开在必须的地方。
适合与不适合
适合：需要一台常驻机器跑长会话压缩、把助手会话从数小时拉到数天的开发者；用 SSH 隧道访问管理面、接受「默认只绑回环」这套安全姿态的运维；需要在 ECS 上给多台内网 agent 统一接一层压缩代理的团队。
不适合：想让代理直接对公网提供服务、又不打算加鉴权与防火墙的场景 —— 它在 --host 0.0.0.0 下完全没有鉴权；对「早期」状态敏感的生产环境 —— 真实模型集成测试还是下一里程碑；以 Windows 客户端为主的团队 —— 会话目录被 Defender 或 OneDrive 锁住会导致写入 EPERM，需要把该目录加入杀软排除项并停掉同步。
标签：亿级上下文压缩、DeepSeek Harness、阿里云 ECS、代理部署
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
