核心功能
localhost-bridge 是一种 Docker 网络桥接方案，专门解决容器化 AI 代理部署中最常见的网络问题：容器内部无法访问宿主机上绑定到 127.0.0.1 的服务（如 AI 网关、MCP 服务器、Ollama、数据库等）。
该方案利用 socat 在 Docker 网桥网关 IP 上监听请求，并转发到宿主机的回环地址，配合精细的防火墙规则，实现容器对本地服务的安全访问，同时避免将服务暴露到外部网络。
显著优点
1. 精准解决痛点：直击 Docker 网络隔离的核心矛盾——容器内 localhost 指向自身而非宿主机
2. 安全性可控：socat 仅绑定内部网桥 IP（172.x.x.1），防火墙规则限定在特定 bridge 接口，宿主机端口不对外暴露
3. 生产级部署：systemd 服务化配置，支持自动重启、依赖管理，适合长期运行的 AI 基础设施
4. 场景覆盖广：适用于 Windmill/n8n 工作流编排、RAG 管道、MCP 代理等多种 AI 应用场景
潜在局限
- 多网络复杂度：容器跨多个 Docker 网络时，需为每个网络单独配置 socat 实例和防火墙规则
- IP 动态变化：Docker 重启后网桥网关 IP 可能变更，需手动更新配置
- 调试门槛高：防火墙静默丢包导致 30 秒超时无错误信息，定位困难
- Linux 绑定：依赖 systemd 和 UFW，Windows/macOS 需改用对应机制
适用人群
- 在 Docker 中部署 AI 工作流（Windmill、n8n）需要连接宿主机 Ollama/LiteLLM 的开发者
- 构建 MCP 服务器与容器化代理通信的系统架构师
- 需在容器内访问宿主机本地数据库/缓存的 DevOps 工程师
常规风险
| 风险点 | 说明 |
|--------|------|
| 防火墙配置遗漏 | 未添加 UFW 规则会导致连接静默超时，是最常见故障 |
| 服务绑定范围错误 | socat 若绑定 0.0.0.0 会将内部服务暴露到公网 |
| 网络变更后失效 | Docker 网络重建后需检查并更新网关 IP |
| 多实例冲突 | 同一端口在不同网络复用需避免配置重叠 |
安全等级
该方案在正确配置下安全性良好：socat 限定内网 IP、防火墙细粒度控制、外部不可达验证。但配置错误（尤其是防火墙规则和绑定地址）可导致服务暴露或连接故障，需严格按文档执行验证步骤。