docker容器访问宿主机服务需按系统选择方案：macos/windows用host.docker.internal，linux用宿主机局域网ip或--add-host=host.docker.internal:host-gateway，避免localhost；bridge模式默认适用出向通信，入向需-p端口映射，macvlan可提供真实局域网ip。
要让 Docker 容器和外部系统（比如局域网设备、宿主机上的数据库、公网服务）安全可靠互通，关键不是“选一种模式就万事大吉”，而是根据通信方向（容器→外部 / 外部→容器）、隔离要求、网络环境来匹配最合适的网络方案。macvlan 是唯一能让容器获得真实局域网 IP、被直连访问的方案；bridge 模式适合大多数对外调用场景；host 模式仅限高性能且可接受弱隔离的特殊情况。
明确通信方向再选网络模式
容器主动访问外部（如请求 API、连 MySQL）和外部主动访问容器（如浏览器访问 Web 服务），适用策略完全不同：
- 容器 → 外部（出向）：默认 bridge 模式完全够用。容器通过 NAT 经宿主机发出请求，只要宿主机能上网、防火墙放行对应端口（如 443、3306），容器就能正常访问。无需额外配置。
-
外部 → 容器（入向）：bridge 模式必须靠
-p端口映射 + iptables 转发，本质是“宿主机代收代转”；macvlan 则让容器自己拥有局域网 IP，外部设备直接访问http://192.168.1.110，不经过宿主机转发，延迟更低、拓扑更透明。 -
容器 ↔ 宿主机服务（如本地 MySQL）：不要用
localhost或127.0.0.1。Linux 下用宿主机真实局域网 IP（如192.168.1.15）；Mac/Windows Docker Desktop 可用host.docker.internal（需确认已启用）。
bridge 模式下安全暴露服务的实操要点
这是最常用也最容易出问题的场景。重点不在“能不能通”，而在“怎么通得稳、管得住”：
- 避免绑定到
0.0.0.0所有接口，尤其在公网服务器上。用-p 127.0.0.1:8080:80限制只允许本机访问；若需局域网访问，指定宿主机内网 IP：-p 192.168.1.15:8080:80。 - 多个容器映射同一端口会冲突，建议统一规划端口段（如 Web 类用 80xx，API 类用 90xx）。
- 配合防火墙（如 ufw）严格控制入站规则：只开放必需端口，关闭其他所有入口。
- 敏感服务（如数据库管理界面）绝不映射到公网 IP，应通过 SSH 隧道或反向代理（Nginx + Basic Auth）做二次保护。
macvlan 模式落地前必须确认的三件事
它强大，但不是“一设就灵”。跳过验证极易导致容器失联或网络紊乱：
-
物理网卡名准确无误：运行
ip a，找状态为UP的主网卡（常见是ens33、enp0s3、eth0），不是docker0或lo。 -
子网参数完全对齐：
--subnet=192.168.1.0/24必须和宿主机 IP 所在网段一致；--gateway=192.168.1.1必须是路由器真实网关地址。 - 交换机/路由器支持多 MAC：家用路由器常默认开启“端口安全”或“AP 隔离”，会丢弃非宿主机 MAC 的包。需登录后台关闭「MAC 地址绑定」、「客户端隔离」或开启「混杂模式」（部分型号叫“桥接模式”）。
连接宿主机服务时的稳定写法
容器访问宿主机上运行的服务（MySQL、Redis、自建 API），最容易踩的坑是地址写错：
- Linux 环境：用宿主机局域网 IP（
192.168.1.15），确保该服务监听0.0.0.0:3306而非127.0.0.1:3306；同时检查防火墙是否放行该端口。 - Docker Desktop（Mac/Win）：优先用
host.docker.internal，它会被自动解析为宿主机网关地址；若失效，在docker-compose.yml中显式声明：extra_hosts: ["host.docker.internal:host-gateway"]。 - 避免硬编码：把 DB_HOST、API_URL 等作为环境变量注入容器，便于不同环境切换，也利于后续接入配置中心。
