Service Fabric HTTPS端点（Kestrel+反向代理）部署后异常求助

我来帮你梳理几个关键的排查方向——这类本地正常但部署到Azure后出问题的情况，大多和环境差异、证书配置或者网络路由有关，你可以按下面的步骤逐一排查：

本地测试用的自签证书在Azure环境里可能不被信任，或者证书配置存在不一致：

• 先确认集群证书和反向代理证书的状态：在Azure门户的Service Fabric集群页面，进入「证书」选项卡，检查证书是否有效未过期，且证书的主体名称/ SAN完全匹配你的API域名。
• 核对ServiceManifest的Endpoint配置：确保Endpoint的Protocol设为https，Port和ClusterManifest里的反向代理端口无冲突；同时确认CertificateRef指向的证书thumbprint和Azure集群中部署的证书完全一致。
• 验证ARM模板的证书部署逻辑：检查ARM模板中virtualMachineScaleSets的secrets配置，确认证书来源的Key Vault路径正确，且集群节点有访问Key Vault的权限（可以通过Key Vault的「访问策略」验证）。

网络路由或端口绑定错误是这类问题的常见原因：

• 检查InstanceListener的HTTPS绑定逻辑：确保代码中Kestrel或HttpListener正确绑定了HTTPS证书，尤其是部署到Azure后，要使用本地机器证书存储而非本地文件路径。示例代码参考：

return new ServiceInstanceListener(serviceContext =>
    new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
    {
        var endpoint = serviceContext.CodePackageActivationContext.GetEndpoint("ServiceEndpoint");
        return new WebHostBuilder()
            .UseKestrel(options =>
            {
                options.Listen(IPAddress.IPv6Any, endpoint.Port, opts =>
                {
                    opts.UseHttps(StoreName.My, StoreLocation.LocalMachine, thumbprint: "YOUR_CERT_THUMBPRINT");
                });
            })
            .UseStartup<Startup>()
            .Build();
    }));

• 确认反向代理的路由规则：访问API时要使用正确的反向代理路径格式：https://<cluster-fqdn>:<reverse-proxy-port>/<app-name>/<service-name>/api/[path]，同时检查ClusterManifest中ReverseProxy是否启用了HTTPS，端口是否在NSG中开放。
• 检查NSG入站规则：确保集群节点的网络安全组（NSG）添加了允许HTTPS流量的规则，覆盖API自身端口和反向代理端口（比如默认的19081）。

本地和Azure环境的AD配置可能存在差异：

• 更新Azure AD应用注册的配置：把本地测试用的localhost回调URI、应用ID URI，替换为部署后的API域名对应的地址，确保重定向URI和应用ID URI与生产环境完全匹配。
• 核对认证代码的参数：检查Startup中的Azure AD认证配置，确认Authority和Audience参数正确指向了目标租户和应用注册的资源ID，避免本地测试的租户ID残留。示例：

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://login.microsoftonline.com/YOUR_PRODUCTION_TENANT_ID";
        options.Audience = "api://YOUR_PRODUCTION_APP_ID_URI";
    });

• 验证证书链信任：Azure AD的Token依赖微软根证书，确保集群节点的证书存储包含完整的信任链，避免因根证书缺失导致Token验证失败。

如果上面的排查都没找到问题，就需要靠日志定位：

• 启用Service Fabric诊断日志：在Azure门户开启Log Analytics集成，查看ServiceFabricOperationalEvents和应用自定义日志，重点关注证书加载失败、端口绑定异常、认证错误这类关键词。
• 本地模拟Azure环境：用Service Fabric模拟器加载Azure集群的证书（从Key Vault下载），复现部署场景，排查是否是配置遗漏导致的问题。
• 直接访问节点测试：如果集群节点有公网IP，尝试直接访问https://<node-ip>:<api-port>/api/[path]，判断问题出在API自身还是反向代理路由上。

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