Docker容器内访问宿主机端口几种可行方案

很多人在用 Docker 部署项目时都会遇到一个问题：容器里运行的代码，怎么访问宿主机上启动的 MySQL、Redis 或本地调试接口？
如果直接在容器里使用 localhost，往往连不通。
这是因为容器默认有独立的网络命名空间，localhost 指向的是容器本身，而不是宿主机。
本文就针对这个场景，整理几种可行方案，并帮零基础用户规避常见的连接失败问题。

先理解容器访问宿主机的网络基础

Docker 容器默认通过 bridge 网络连接宿主机。
在 bridge 模式下，容器可以访问宿主机上的 IP，不过这个 IP 并不是 localhost，而是宿主机在 Docker 网络中的网关地址，通常由 Docker 自动分配。
不同操作系统的处理方式略有差异，这也是很多新手卡住的主要原因。

要判断当前环境是否支持特殊 DNS 名称，可以先运行一条基础命令查看 Docker 版本和网络信息：

docker version
ip addr show docker0

如果你的宿主机是 Linux，docker0 网卡的 IP 一般就是容器的默认网关，通常为 172.17.0.1。
在容器内访问这个 IP，就等于访问宿主机。
不过这个地址在不同版本或自定义网络中可能变化，更稳妥的做法是下面讲的几种方案。

方案一：使用 host.docker.internal 访问宿主机

host.docker.internal 是 Docker 提供的一个特殊域名，专门用于从容器内部访问宿主机。
在 Docker Desktop 的 Mac 和 Windows 版本中，这个域名默认可用，无需额外配置。

在容器内测试连通性：

docker run --rm alpine ping host.docker.internal

如果容器内应用需要连接宿主机的 MySQL，连接地址可以这样写：

jdbc:mysql://host.docker.internal:3306/db_name

redis://host.docker.internal:6379

注意：在 Linux 系统下，host.docker.internal 在老版本 Docker 中不一定生效。
你可以使用 docker run --add-host=host.docker.internal:host-gateway 把域名指向宿主机网关，例如：

docker run --add-host=host.docker.internal:host-gateway -p 8080:80 my_image

这种方式兼容性较好，且不需要修改容器内代码。
如果你的 Docker 版本较新，加了 --add-host 后，安装 Docker 时通常已经默认支持 host-gateway，可以直接在 compose 文件中配置：

services:
  app:
    image: nginx
    extra_hosts:
      - "host.docker.internal:host-gateway"

方案二：使用宿主机物理 IP 或 docker0 网关 IP

当 host.docker.internal 在 Linux 上不可用时，最简单直接的办法是在容器内使用宿主机的物理 IP 地址。
先查一下宿主机的局域网 IP，例如 192.168.1.100，然后在容器内访问 192.168.1.100:端口。

如果宿主机有防火墙，要确保允许容器访问宿主机的对应端口。
在容器内测试：

docker run --rm alpine wget -qO- http://192.168.1.100:8080

另一个更稳定的方式是使用 docker0 网卡的 IP。
在宿主机上执行：

ip addr show docker0

通常输出里会看到 inet 172.17.0.1/16，那么在容器内就用 172.17.0.1 访问宿主机服务。
这个方案在新装 Docker 的 Linux 环境中基本通用，但如果宿主机修改过 bridge 网段，就需要以实际输出为准。

方案三：直接改用 host 网络模式

如果业务场景允许，直接把容器网络模式设为 host，容器就会与宿主机共享网络栈。
此时容器里的 localhost 就是宿主机 localhost，不需要再考虑 IP 映射问题。

使用命令运行容器：

docker run --network host my_image

在 docker-compose.yml 中对应写法为：

services:
  app:
    image: my_image
    network_mode: host

适用场景：本地开发调试、需要访问宿主机大量端口、对网络性能要求较高的场景。
但要注意，host 模式会占用宿主机端口，容器端口映射配置 -p 会失效，且不支持 Docker 网络隔离，生产环境使用时要谨慎评估安全风险。

避坑指南：这三个问题最容易导致连接失败

很多用户明明配置了方案，却还是连不上宿主机端口，最常见的三个原因如下。

第一，宿主机服务只监听了 127.0.0.1。 如果你的 MySQL、Redis 或自定义服务只绑定在 127.0.0.1，那么无论容器用哪种方式访问，都会因为宿主机服务没有监听外部接口而失败。
解决办法是修改服务配置文件，把监听地址改为 0.0.0.0 或 宿主机物理 IP。
例如 MySQL 的 my.cnf 中：

bind-address = 0.0.0.0

修改后重启对应服务。

第二，宿主机防火墙拦截了容器 IP。 在 Linux 上，iptables、firewalld 或云安全组可能阻止容器访问宿主机端口。
可以先临时关闭防火墙测试：

systemctl stop firewalld

如果确认是防火墙问题，再按需放行端口或源地址，不要长期关闭防火墙。

第三，使用了过旧的 Docker 版本。 host-gateway 功能在 Docker 20.10 之后才逐步完善，如果你用的版本很老，建议先升级 Docker，或改用手动指定网关 IP 的方式。
运行 docker --version 即可查看当前版本。

如何验证容器到宿主机端口已经通了

验证步骤建议按下面流程进行，避免漏判。

先在宿主机上确认端口监听状态：

ss -lntp | grep 3306

再运行一个临时容器测试连通性，例如检查宿主机 3306 端口：

docker run --rm alpine nc -zv host.docker.internal 3306

如果你使用的是网关 IP，可以把 host.docker.internal 换成具体 IP。
若命令输出类似 Connected to ...，说明容器内访问宿主机端口已经成功；
如果超时或拒绝连接，再回到避坑部分逐项排查。

总结与选型建议

给零基础用户的结论是：在 Mac 或 Windows 的 Docker Desktop 上，优先使用 host.docker.internal；
在 Linux 服务器上，推荐网关 IP 或 --add-host 方式；
如果只是本地调试且不介意端口冲突，可以直接用 host 网络模式。 这三种方法都能解决容器内访问宿主机端口的需求，但没有绝对万能的方式。
如果你的镜像要跨环境部署，建议在容器内通过环境变量传入宿主机地址，这样切换环境时不需要改代码。
实际部署时，请以你自己环境的 Docker 版本和服务监听状态为准，逐步验证。