Windows容器内C#客户端访问本地WCF服务通信失败问题

核心问题出在你当前使用的netNamedPipeBinding绑定本身的机制限制，和容器的隔离特性冲突：

• netNamedPipeBinding依赖Windows系统的内核级命名管道实现同机跨进程通信，这类内核对象在容器环境下是被隔离的：每个容器拥有独立的内核对象命名空间，即使两个容器部署在同一台物理宿主机上，一个容器内创建的命名管道，另一个容器通过localhost完全无法访问。
• 物理机直接运行时客户端和服务同属宿主机的内核命名空间，通信链路正常；容器化部署后如果客户端和WCF服务分属不同容器，根本找不到对应命名管道，直接抛出通信异常。
• 如果你是把服务和客户端放在同一个容器内仍报错，一般是两个进程启动顺序问题（客户端发起请求时WCF服务还没完成监听），或者容器运行身份的权限不足导致命名管道ACL拦截。

根据你的部署架构选对应方案即可：

• 方案1（推荐，适配容器部署逻辑）：替换跨容器不兼容的命名管道绑定
  弃用netNamedPipeBinding，改用支持TCP网络通信的netTcpBinding：
  1. 服务端将绑定替换为netTcpBinding，指定固定监听端口（如8080），启动服务容器时做好端口映射，或者把服务容器和客户端容器加入同一个自定义容器网络。
  2. 修改客户端WCF配置：将绑定替换为对应参数的netTcpBinding，endpoint地址从原来的net.pipe://localhost/xxx改成服务的可访问地址：同自定义网络下直接用服务容器名作为主机名即可，例如net.tcp://dpcs-service:8080/Intel/E3/DPCSService；如果做了端口映射到宿主机，也可以写宿主机的物理IP+映射端口。测试环境可以先把绑定安全模式设为None，先跑通通信再按需调整安全配置。
• 方案2（保留命名管道，性能最优）：同容器部署两个进程
  如果你对IPC通信性能要求极高，不想引入TCP协议栈开销，可以把WCF后台服务和C#客户端打包进同一个容器镜像：
  1. 写容器启动脚本，先启动WCF后台服务进程，等待服务监听就绪（一般轮询2-3秒即可）后再启动客户端应用。
  2. 这种场景下两个进程共享容器的内核命名空间，你原来的net.pipe://localhost配置不需要任何修改就能正常通信。
• 额外排查项：同容器部署仍报错时，检查两个进程的运行身份是否一致，你当前已经把命名管道的安全模式设为None，基本不会出现ACL权限拦截问题，优先排查服务启动顺序即可。

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