核心用法
localhost-bridge 使用 socat 在Docker网桥网关IP上监听，将流量转发至主机的127.0.0.1，使容器能访问宿主机仅绑定localhost的服务（如Ollama、MCP服务器、PostgreSQL等）。部署涉及三个关键步骤：确定目标容器的网桥网关IP、创建绑定特定IP的systemd服务、添加针对Docker网桥接口的UFW防火墙规则。
显著优点
- 精准解决痛点：直接应对"容器内localhost指向自身而非宿主机"的经典网络隔离问题
- 最小暴露面：通过绑定特定Docker网桥IP（172.x.x.1）和接口级防火墙规则，避免服务对外暴露
- 生产级持久化：systemd服务确保重启后自动恢复，相比临时方案更可靠
- 多网络支持：可为同一容器在多个Docker网络分别建立独立桥接
- 自文档化命名：
socat-<源网络>-<目标服务>-<端口>的命名规范便于运维追溯
潜在缺点与局限性
- 高权限依赖：需要sudo、Docker守护进程访问和systemd服务创建权限，无法在无特权环境运行
- 手动审核负担：每次部署必须人工审查生成的service文件和防火墙规则，无法自动化
- IP动态风险：Docker重启后网桥IP可能变化，需手动更新配置
- 单点转发开销：每个目标端口需独立socat进程，端口较多时管理复杂
- Linux限定：
host.docker.internal方案在Mac/Windows可用，但本技能主要针对Linux服务器环境
适合人群
- AI基础设施运维：部署MCP服务器、Ollama、LiteLLM等需被容器化工作流访问的本地服务
- Docker化Agent开发者：构建需要回连宿主机服务的自治代理系统
- 安全敏感型企业：需在保持网络隔离的同时实现容器-主机通信的场景
常规风险
| 风险类型 | 说明 | 缓解措施 |
|---------|------|---------|
| 错误绑定暴露 | socat绑定0.0.0.0而非特定IP导致公网可访问 | 部署前强制审查`ExecStart`行的bind参数 |
| 防火墙规则误配 | 错误指定网桥接口可能意外开放服务 | 通过`docker network inspect`获取准确bridge ID，用`ip link show`验证 |
| 特权滥用 | 自动化代理未经授权执行高权限命令 | 技能明确禁止自主执行，必须人工审批 |
| 隐蔽超时故障 | 缺失UFW规则时容器请求静默丢弃，30秒超时难排查 | 部署后强制双向验证（容器内成功+公网失败） |
本技能将常见的"localhost陷阱"问题转化为可审计、可回滚的系统级配置，适合已具备Linux系统管理能力的团队在生产环境采用。