这个问题我碰到过好几次，核心原因是WCF和Java生态的SOAP Fault格式细节不兼容，再加上安全配置的小问题，导致你没法正常捕获和解析错误信息。咱们一步步来解决：

1. 先扩大异常捕获范围，捕获通用FaultException #

你当前只捕获了泛型的FaultException<WyjatekTyp>，但因为WCF无法将Java返回的Fault正确反序列化为WyjatekTyp（大概率是命名空间不匹配、XML结构差异），所以这个分支根本不会触发。先改成捕获通用的FaultException，甚至先抓CommunicationException（因为你看到的错误属于通信层异常）：

try
{
    client.Open();
    SkrytkaReference.OdpowiedzSkrytkiTyp response = new SkrytkaReference.OdpowiedzSkrytkiTyp();
    SkrytkaReference.DokumentTyp dokument = new SkrytkaReference.DokumentTyp();
    dokument.nazwaPliku = model.Dokument.nazwaPliku;
    dokument.typPliku = model.Dokument.typPliku;
    dokument.zawartosc = model.Dokument.zawartosc;
    response = client.nadaj(model.IdentyfikatorPodmiotu, model.AdresSkrytki, model.AdresOdpowiedzi, true, model.DaneDodatkowe, dokument);
    client.Close();
}
// 先抓通用FaultException
catch (FaultException ex)
{
    var msgFault = ex.CreateMessageFault();
    if (msgFault.HasDetail)
    {
        // 手动解析Fault细节的XML，绕开反序列化问题
        using (XmlReader reader = msgFault.GetReaderAtDetailContents())
        {
            XmlDocument detailDoc = new XmlDocument();
            detailDoc.Load(reader);
            // 这里就能拿到完整的错误XML内容，你可以提取具体字段
            string errorContent = detailDoc.InnerXml;
            // 比如如果Java返回的错误有<errorMessage>节点，就用XPath获取
            XmlNode errorNode = detailDoc.SelectSingleNode("//errorMessage");
            if (errorNode != null)
            {
                string errorMsg = errorNode.InnerText;
                // 处理错误信息
            }
        }
    }
    // 还能获取Fault的Reason和Code
    string faultReason = ex.Reason.ToString();
    string faultCode = ex.Code.Name;
}
// 抓通信层异常，里面可能嵌套FaultException
catch (CommunicationException ex)
{
    if (ex.InnerException is FaultException faultEx)
    {
        // 复用上面的解析逻辑
        var msgFault = faultEx.CreateMessageFault();
        if (msgFault.HasDetail)
        {
            using (XmlReader reader = msgFault.GetReaderAtDetailContents())
            {
                XmlDocument detailDoc = new XmlDocument();
                detailDoc.Load(reader);
                string errorContent = detailDoc.InnerXml;
            }
        }
    }
    else
    {
        // 处理其他通信错误，比如连接超时、安全配置问题
        string innerError = ex.InnerException?.Message ?? ex.Message;
    }
}
finally
{
    // 确保客户端正确关闭，避免资源泄漏
    if (client.State != CommunicationState.Closed)
    {
        client.Abort();
    }
}

2. 解决“不安全或安全设置错误”的根源 #

你看到的这个提示，说明WCF客户端和Java服务的安全配置不匹配，比如：

• Java服务启用了SSL，但客户端绑定没设置security mode="Transport"
• 认证方式不匹配（比如Java用基本认证，客户端没配置clientCredentialType="Basic"）

调整客户端配置文件的绑定设置，比如如果是BasicHttpBinding：

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding name="SkrytkaServiceBinding">
        <!-- 根据Java服务的实际情况选择None/Transport/TransportWithMessageCredential -->
        <security mode="Transport">
          <transport clientCredentialType="None"/> <!-- 或者Basic/Windows等 -->
        </security>
      </binding>
    </basicHttpBinding>
  </bindings>
  <client>
    <endpoint address="Java服务的URL"
              binding="basicHttpBinding"
              bindingConfiguration="SkrytkaServiceBinding"
              contract="SkrytkaReference.你的契约接口名"/>
  </client>
</system.serviceModel>

3. 修复WSDL代理类的命名空间问题 #

如果后续想回到泛型FaultException<WyjatekTyp>的捕获，需要确保代理类中的WyjatekTyp的命名空间和Java服务返回的Fault细节的XML命名空间完全一致。你可以：

• 用svcutil.exe生成代理时，加上/namespace参数强制指定命名空间，比如：

  svcutil.exe http://Java服务的WSDL地址 /namespace:*,SkrytkaReference /out:SkrytkaProxy.cs
  

• 手动修改代理类中WyjatekTyp的DataContract特性的Namespace属性，和Fiddler里看到的Java返回的Fault细节的XML命名空间保持一致。

总结 #

先通过捕获通用异常+手动解析XML的方式拿到错误信息，再解决安全配置不匹配的问题，最后如果需要优雅的泛型捕获，再调整代理类的命名空间。这样就能彻底解决你现在的问题，不用再依赖Fiddler看请求响应了。

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