核心用法
localhost-bridge使用socat在Docker网桥网关IP上监听流量，并转发到主机的127.0.0.1，从而让容器能够访问主机上绑定到localhost的服务（如AI网关、MCP服务器、Ollama、数据库等）。配置流程包括：查询容器的Docker网桥网关IP、创建systemd持久化服务、添加UFW防火墙规则限定特定网桥接口，最后进行安全验证（容器内可访问、公网不可访问）。
显著优点
1. 解决根本性网络隔离问题：填补了Docker容器无法直接访问主机localhost的标准缺口，是AI基础设施部署的常见痛点
2. 细粒度安全控制：通过bind到特定Docker网桥IP+UFW规则限定接口，避免服务暴露到公网
3. 生产级持久化：systemd服务确保重启后自动恢复，比临时进程更可靠
4. 多网络支持：可为同一容器的多个Docker网络分别配置独立桥接
潜在缺点与局限性
1. 高权限依赖：需要sudo、Docker daemon访问、systemd服务创建——攻击面显著扩大
2. 配置复杂度高：需手动确认网桥ID、网关IP、端口映射，任一错误可能导致安全暴露或服务故障
3. 非原子性风险：systemd服务和UFW规则分离配置，可能出现服务启动但防火墙未生效的窗口期
4. Linux兼容性限制：host.docker.internal方案在Docker Desktop可用但Linux不可靠，被迫采用更复杂的socat方案
5. IP漂移问题：Docker重启后网桥IP可能变化，需人工更新配置
适合人群
- 在Linux服务器上部署容器化AI工作流（Windmill、n8n等）的DevOps/平台工程师
- 需要让Docker化Agent访问主机MCP服务器或本地LLM（Ollama）的AI基础设施团队
- 具备Linux网络调试能力、能手动审查systemd unit文件和UFW规则的安全意识团队
常规风险
- 配置错误导致公网暴露：socat若bind到0.0.0.0而非特定Docker网桥IP，服务将对外可见
- 权限提升攻击面：自动化代理若获得sudo执行此skill，可被诱导创建持久化后门服务
- 隐蔽性超时故障：UFW规则缺失时表现为30秒无响应超时，易误判为服务问题而非网络层阻断
- 供应链风险：依赖发行版官方socat包，但skill本身未校验包签名