同Docker容器内.NET 5应用连接自定义SDK的TCP/Telnet失败问题排查

看起来你遇到的是同一个Docker容器内进程间TCP连接的问题，结合你的描述，我梳理了两个最可能的原因和对应的解决办法：

1. 核心问题1：SDK没有随容器自动启动（最可能的根源） #

仔细看你的Dockerfile，你只是把SDK复制到了/sdk目录，但没有配置让它和.NET应用一起启动。Docker容器默认只会运行ENTRYPOINT指定的主进程（也就是你的MyProject.Server.dll），所以当容器启动时，SDK其实是没有运行的——除非你手动进入容器终端启动它。这就解释了为什么你手动进入容器后telnet能通，但应用自己运行时连不上：应用启动时SDK根本没在跑！

解决办法：用启动脚本同时启动两个进程 #

编写一个简单的shell启动脚本（比如start.sh），放在你的项目根目录：

#!/bin/bash
# 后台启动SDK（替换成你的SDK实际可执行文件名）
/sdk/SomeSDK &
# 启动.NET应用（主进程，保持前台运行）
dotnet MyProject.Server.dll

然后修改Dockerfile的final阶段，添加脚本复制和权限设置：

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
# 复制启动脚本
COPY start.sh .
# 给脚本添加执行权限
RUN chmod +x start.sh
# 替换原来的ENTRYPOINT
ENTRYPOINT ["./start.sh"]

这样容器启动时，会先后台启动SDK，再启动.NET应用，确保两个进程同时运行。

2. 核心问题2：localhost解析优先级导致的IPv6/IPv4不兼容 #

如果确认SDK已经和应用一起启动了，但还是连不上，那大概率是localhost解析的问题：在Linux容器中，localhost默认会优先解析到IPv6的::1，但如果你的SDK只监听了IPv4的127.0.0.1，那么应用用localhost连接时会尝试IPv6地址，自然被拒绝。

解决办法： #

• 方案A：强制使用IPv4地址连接
  把代码里的"localhost"改成"127.0.0.1"，让应用明确用IPv4连接：

  var telnetClient = new TelnetClient("127.0.0.1", 54321, TimeSpan.FromSeconds(1), new CancellationToken());
  

• 方案B：让SDK监听所有地址
  检查SDK的配置，把它的监听地址从127.0.0.1改成0.0.0.0（监听所有IPv4地址）或者::（监听所有IPv6地址，兼容IPv4）。这样不管应用用IPv4还是IPv6连接，都能成功。

验证方法： #

在容器终端执行netstat -tulpn | grep 54321，查看SDK的监听地址：

• 如果显示127.0.0.1:54321：说明只监听IPv4，应用用localhost（IPv6）会失败
• 如果显示:::54321或0.0.0.0:54321：说明监听所有地址，不会有解析问题

额外验证步骤 #

1. 容器启动后，先不要进入终端，直接用docker exec <容器ID> telnet 127.0.0.1 54321测试连接，看是否能通——这能模拟应用运行时的环境（不需要手动启动SDK）。
2. 如果用127.0.0.1能通，但localhost不能，那就是IPv6的问题，按照方案A修改代码即可。

内容的提问来源于stack exchange，提问作者Daniël Camps