我太懂你这种卡了好几天的崩溃感——明明能正常访问Swagger，可客户端调用API就报SSL握手错误，试过常规的证书绕过方案完全没用。咱们先拆解下问题：你看到的The handshake failed due to an unexpected packet format错误，其实根本不是证书信任的问题，而是SSL/TLS握手在更早的协议协商阶段就失败了，导致你配置的ServerCertificateCustomValidationCallback甚至没机会执行。

下面是针对你的场景的具体解决步骤：

1. 强制指定TLS版本 #

MacOS Big Sur默认禁用了TLS 1.0和1.1，如果你的IIS Express服务只支持这些旧协议，就会出现握手失败。给HttpClientHandler明确指定支持的TLS版本：

services.AddHttpClient<ISubmitter, Submitter>(httpClient => 
    httpClient.BaseAddress = new Uri("https://192.168.86.150:4433"))
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler {
    ClientCertificateOptions = ClientCertificateOption.Manual,
    ServerCertificateCustomValidationCallback = (_, _, _, _) => true,
    // 强制使用TLS 1.2和1.3，适配MacOS的安全策略
    SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13
});

2. 禁用系统代理干扰 #

MacOS的系统代理或者VS for Mac的代理设置可能会拦截请求，导致数据包格式异常。在Handler里直接禁用代理：

.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler {
    // ... 其他配置
    UseProxy = false,
    Proxy = null
});

3. 绕过依赖注入的潜在配置覆盖 #

有时候AddHttpClient的链式配置可能被项目中其他服务的配置覆盖，尝试手动创建Handler和HttpClient再注入：

// 在ConfigureServices中
var sslHandler = new HttpClientHandler
{
    ClientCertificateOptions = ClientCertificateOption.Manual,
    ServerCertificateCustomValidationCallback = (_, _, _, _) => true,
    SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13,
    UseProxy = false
};

var submitterClient = new HttpClient(sslHandler)
{
    BaseAddress = new Uri("https://192.168.86.150:4433")
};

services.AddSingleton<ISubmitter>(new Submitter(submitterClient));

4. 用curl验证服务端SSL配置 #

先在Mac终端用curl测试，确认服务端的SSL是否能正常响应：

# -k 跳过证书校验，-v 显示详细握手日志
curl -k -v https://192.168.86.150:4433/api/gateway/submit -X POST

如果curl能成功返回，说明问题出在客户端代码配置；如果curl也报类似的握手错误，那你需要检查IIS Express的SSL绑定配置，确保它启用了TLS 1.2+，并且没有防火墙/端口映射的问题。

为什么之前的方案无效？ #

你之前用的ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator确实能跳过证书校验，但这个回调是在SSL握手成功、证书验证阶段才会触发的。而你的错误发生在握手初期的协议协商阶段，所以这个回调根本没机会运行，自然无效。

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