我来帮你捋捋这个问题的根源，一步步解决它：

核心问题分析 #

从你给出的信息来看，最关键的点是宿主机执行lsof -i tcp:9000看不到监听进程，这说明哪怕用了--net=host，容器里的gRPC服务也没在宿主机的9000端口上监听。结合错误日志里的target_address":"ipv6:[::1]:9000"，大概率是容器内的服务只绑定了回环地址（127.0.0.1或[::1]），而不是允许外部访问的0.0.0.0。

分步排查与解决 #

1. 先确认容器内服务的监听地址 #

这是最核心的一步，先搞清楚服务在容器内部到底监听了哪个地址：

# 先正常启动容器（不用--net=host，用端口映射）
sudo docker run --rm -d -p 9000:9000 -u dud --entrypoint=/usr/local/bin/application COOL_APP
# 获取容器ID并进入容器
CONTAINER_ID=$(sudo docker ps -qf "name=COOL_APP")
sudo docker exec -it $CONTAINER_ID bash
# 在容器内检查端口监听
netstat -tulpn | grep 9000

如果输出显示类似127.0.0.1:9000，那问题就找到了：你的gRPC服务只监听了容器内部的回环地址，外部根本访问不到。

解决方法：修改gRPC服务的代码或启动参数，让它绑定0.0.0.0:9000，而不是localhost或127.0.0.1。比如在服务启动代码里，把监听地址从localhost改成0.0.0.0。

2. 针对不同系统调整Docker网络配置 #

Docker的网络模型在Linux和macOS/Windows上有差异，这也是容易踩坑的点：

• Linux环境：
  • 如果用--net=host，只要容器内服务监听0.0.0.0:9000，宿主机的Python客户端直接用localhost:9000就能连接。
  • 不用host网络的话，用-p 0.0.0.0:9000:9000映射端口，客户端同样用localhost:9000。
• macOS/Windows环境：
  • Docker是运行在虚拟机里的，--net=host其实是让容器共享虚拟机的网络，不是宿主机的。所以这种情况下localhost访问不了，你需要用Docker虚拟机的IP来连接：

    # 获取Docker虚拟机IP（macOS示例）
    docker run --rm alpine ip route | grep default | awk '{print $3}'
    

    然后客户端把HOST改成这个IP，比如HOST = '192.168.65.2'，再连接9000端口。

3. 排查权限问题 #

你启动容器时用了-u dud，虽然9000不是特权端口（低于1024才需要root），但如果dud用户在容器内没有足够权限启动服务，可能导致服务静默失败，自然看不到端口监听。可以先去掉-u dud，用root用户启动容器试试：

sudo docker run --rm -it --net=host --entrypoint=/usr/local/bin/application COOL_APP

如果服务能正常监听端口，那就是dud用户的权限问题，需要调整容器内用户的权限配置。

4. 验证端口连通性 #

不管用哪种网络模式，都可以先测试宿主机到容器端口的连通性：

# 如果是Linux且用host网络，直接测localhost
nc -zv localhost 9000
# 如果是端口映射或macOS/Windows，测容器IP或虚拟机IP
nc -zv <容器/虚拟机IP> 9000

如果连接成功，说明网络没问题，问题出在客户端代码或gRPC服务的业务逻辑上；如果连接失败，还是回到前面的监听地址和网络配置排查。

关于你测试hello-world容器的问题 #

你用-p 9000:9000运行hello-world容器时出现Socket closed，大概率是那个容器的gRPC服务和你的Python客户端版本不兼容，或者服务本身的问题，和你的核心问题无关，不用纠结这个。

内容的提问来源于stack exchange，提问作者H. Desane