Host网络模式下反向代理需独占宿主机80/443端口，Nginx须监听0.0.0.0:80且配置proxy_set_header透传真实IP，后端服务应使用bridge网络实现DNS发现，避免端口冲突与权限风险。
Host 网络配合反向代理能显著减少网络跳转层级，把延迟压到最低，但必须清楚它不是“开箱即用”的组合——关键在于谁来当反向代理、谁来监听端口、以及如何避免冲突。
反向代理必须运行在 host 网络中
只有反向代理自身使用 host 网络模式，才能直接绑定宿主机的 80/443 端口，绕过 Docker 的 NAT 和 iptables 转发。此时它就等同于宿主机上原生运行的 Nginx 或 Traefik：
- 在 docker-compose.yml 中显式设置 network_mode: host，且不写 ports 字段（该字段在 host 模式下被忽略）
- 容器内服务（如 Nginx）需主动监听 0.0.0.0:80，而非仅 127.0.0.1:80（否则外部无法访问）
- 宿主机上不能已有其他进程（如原生 nginx、apache）占用 80/443，否则容器启动会失败
后端服务建议用 bridge 网络互联
反向代理暴露在 host 网络，不等于所有服务都要跟着进 host。后端应用（如 API、前端静态服务）更适合走默认的 bridge 网络：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- bridge 网络提供 DNS 自动发现（如 backend:3000），Nginx 配置里 proxy_pass 可直接写服务名
- 避免多个后端服务也抢 host 端口，降低管理复杂度和冲突风险
- 示例配置中，Nginx（host 模式）→ proxy_pass http://api:8080 → api 服务（bridge 模式，expose: 8080）
必须透传真实客户端信息
因为 host 模式下没有额外的网络层做地址转换，看似“更直”，但若 Nginx 不主动设置请求头，后端将收不到真实 IP 和协议类型：
- 务必在 location 块中加入：proxy_set_header X-Real-IP $remote_addr
- 加上 X-Forwarded-For 和 X-Forwarded-Proto，确保后端能正确判断 HTTPS、用户来源
- WebSocket 场景还需显式启用 upgrade 协议：proxy_http_version 1.1 + proxy_set_header Upgrade $http_upgrade
安全与可观测性不能因性能妥协
host 模式共享宿主机网络栈，意味着容器内进程可读取主机路由表、访问本地套接字，权限边界变弱：
- 禁止在 host 模式容器中运行不受信镜像或调试工具（如 curl、netcat、ss）
- 用 docker inspect 容器名 | grep NetworkMode 定期确认实际网络模式，防止 compose 配置误覆盖
- 日志和监控仍要落盘或对接远程系统，不能依赖容器内部临时存储
