核心用法
localhost-bridge 使用 socat 创建从 Docker 网桥网关 IP 到主机 127.0.0.1 的 TCP 转发，使容器能够访问绑定在主机本地回环地址上的服务（如 AI 网关、MCP 服务器、Ollama、数据库等）。部署流程分为三步：首先通过 docker inspect 获取容器所在网络的网关 IP；其次创建 systemd 服务实现持久化端口转发，服务命名采用自文档化规范 socat-<source_network>-<target_service>-<port>；最后添加 UFW 防火墙规则，仅允许特定 Docker 网桥接口的流量通过，防止服务暴露于公网。
显著优点
精准解决痛点：直接应对容器化 AI 基础设施中最常见的网络困境——容器内 localhost 指向自身而非主机，导致连接超时或拒绝。
安全可控：强制要求人工审核所有配置，包括 systemd 服务的 ExecStart 绑定地址和 UFW 规则的网桥接口，避免 0.0.0.0 开放或错误接口导致的安全漏洞。
生产级持久化：systemd 服务确保重启后自动恢复，配合 Restart=always 策略提升可靠性。
多网络支持：支持容器跨多个 Docker 网络的场景，每个网络可独立配置转发实例。
潜在缺点与局限性
权限门槛高：必须拥有 sudo、Docker daemon 访问权限及 systemd 管理能力，普通开发者难以自助部署。
手动运维负担：Docker 网络重建或 IP 变化时需人工更新配置，缺乏动态适配机制。
平台差异：host.docker.internal 方案在 Linux 上不可靠，本技能主要面向 Linux 服务器环境。
依赖外部工具：需安装 socat，且 systemd 和 UFW 假设可能不适用于所有发行版（如使用 nftables 或 firewalld 的系统）。
适合人群
- 运维工程师和系统管理员管理自托管 AI 基础设施
- 使用 Windmill、n8n 等工作流引擎对接本地 AI 网关的团队
- 需要容器安全访问主机 MCP 服务器或 Ollama 实例的开发者
- 追求网络隔离与本地服务访问平衡的中高级 Docker 用户
常规风险
- 配置错误导致暴露：若
bind=<GATEWAY_IP>误写为0.0.0.0，或服务未配防火墙，本地服务将暴露于公网 - 防火墙规则误配：错误的网桥接口 ID 可能意外开放主机端口
- 特权操作风险：systemd 服务创建和 UFW 规则修改需 root 权限，存在误操作影响系统稳定性可能
- 拒绝自动化执行：明确禁止 AI agent 自主运行，必须在人工审核后手动执行