同一宿主机多Docker容器监听相同端口的Traefik配置方法

你现在的配置从逻辑上就错了，既没搞懂Docker端口映射的规则，也搞混了容器网络的出入站方向，完全没必要上Traefik做反向代理，改几行配置就能解决。

Docker的ports规则格式是宿主机端口:容器端口，作用是把宿主机上收到的、访问对应端口的入站流量，转发到容器内部的指定端口——说白了，只有你需要让宿主机外部的流量主动访问容器里跑的服务时，才需要配这个规则。如果是容器里的程序主动往外发请求（比如连外部MQTT、连宿主机上的数据库），根本不需要配端口映射，容器默认就具备对外访问的网络能力。

针对你提到的两个业务场景，逐个修正配置逻辑即可：

1. 容器向宿主机8086端口的数据库写数据 #

这个场景是容器主动向外发起请求，目标是宿主机的8086端口，和端口映射没有任何关系。你之前给每个容器都配置"8086:80"属于完全反向的操作：这个配置会抢占宿主机的8086端口，把所有访问宿主机8086的流量转到对应容器的80端口，9个容器同时抢同一个宿主机端口，必然启动就报端口冲突，而且这个配置对容器访问宿主机数据库没有任何帮助。

正确的配置方式非常简单：给每个sensor服务加一行extra_hosts配置，把宿主机地址映射到容器内可解析的域名，脚本里的数据库连接地址直接填host.docker.internal:8086就能连通，完全不占用宿主机的8086端口。

2. 容器接收外部MQTT broker的消息 #

这里你大概率搞混了MQTT的客户端/服务端通信逻辑：如果你的Python脚本是作为MQTT客户端，主动连接外部broker的1883端口订阅消息，根本不需要在容器内监听1883端口，也不需要做1883的端口映射。客户端和broker建立TCP长连接之后，broker推送消息是走已经建好的现有连接，不需要客户端本地开端口等待入站流量。

如果你确实有特殊场景需求：每个sensor容器自身就是MQTT服务端，需要外部设备主动连接容器的1883端口，二选一即可：

• 低成本方案：给每个容器分配不同的宿主机端口，比如sensor1映射"1883:1883"、sensor2映射"1884:1883"，依次排到sensor9用1891端口，外部访问时对应不同端口即可，9个服务的量级用这个方案最省事，维护成本几乎为0
• 反向代理方案：用Traefik做TCP层路由，但要求所有接入的MQTT客户端都开启TLS并携带SNI标识，Traefik才能根据SNI把宿主机1883端口的流量分流到不同容器，配置复杂度很高，没有特殊域名路由需求完全不推荐使用

services:
  sensor1:
    build: ./sensor1
    image: sensor1:latest
    extra_hosts:
      - "host.docker.internal:host-gateway"
    # 无对外暴露服务需求时，不需要配置ports项
  sensor2:
    build: ./sensor2
    image: sensor2:latest
    extra_hosts:
      - "host.docker.internal:host-gateway"
  # sensor3到sensor8配置逻辑同上
  sensor9:
    build: ./sensor9
    image: sensor9:latest
    extra_hosts:
      - "host.docker.internal:host-gateway"

对应Python脚本只需要调整两个配置项：

• MQTT连接部分：直接填写外部broker的真实IP/域名，端口1883，作为客户端主动发起连接即可，不要在脚本里绑定本地1883端口做监听
• 数据库连接部分：地址填写host.docker.internal，端口8086，其余账号密码、库表参数和你在宿主机本地连接数据库的配置完全一致

内容的提问来源于stack exchange，提问作者Rikissssss