.NET Core 3.1 Web应用部署至IIS后登录异常问题排查求助

结合你描述的场景（本地IIS用localhost正常，域名访问登录失效），以下是几个最可能的原因及对应的排查/解决步骤：

1. Cookie 域配置不匹配 #

.NET Core认证Cookie默认会根据当前请求的Host生成域属性，当用localhost访问时，Cookie域是localhost；切换到域名domain.com时，之前的Cookie无法被识别，且新生成的Cookie可能因为域配置问题无法被浏览器保存。

解决方法：
在Startup.cs的ConfigureServices方法中显式设置Cookie的Domain属性，确保适配域名场景：

using Microsoft.AspNetCore.Authentication.Cookies;

// ...

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        // 配置为你的顶级域名，前缀加`.`可适配子域名
        options.Cookie.Domain = ".domain.com";
        options.LoginPath = "/Account/Login";
        options.LogoutPath = "/Account/Logout";
    });

2. Cookie安全属性与访问协议冲突 #

如果本地开发使用HTTPS，.NET Core默认会将认证Cookie的Secure属性设为true，即仅在HTTPS请求中传递Cookie。但如果你的域名访问用的是HTTP，浏览器会拒绝保存/发送这个Cookie，导致认证失效。

解决方法：
根据当前环境调整Cookie的安全策略：

options.Cookie.SecurePolicy = CookieSecurePolicy.None; // HTTP环境下使用，生产环境建议配置HTTPS后改为CookieSecurePolicy.Always

3. 反向代理/转发头未正确配置 #

如果你的域名是通过反向代理（如IIS ARR、Nginx）指向IIS站点，.NET Core可能无法正确识别原始请求的Scheme（HTTP/HTTPS）和Host，导致认证流程中生成的回调URL或Cookie信息错误。

解决方法：
在Startup.cs的Configure方法开头添加转发头中间件：

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

同时确保反向代理服务器正确传递X-Forwarded-Proto、X-Forwarded-Host等请求头。

4. IIS URL重写规则干扰 #

如果你的IIS站点配置了URL重写规则（比如强制HTTPS重定向、路径重写），可能会导致登录请求的ReturnUrl参数丢失，或者认证回调路径被篡改，从而触发登录失败后跳转回默认路由。

排查方法：

• 打开浏览器开发者工具的「Network」标签，查看登录请求的跳转过程，确认是否有异常的重定向。
• 暂时禁用所有自定义URL重写规则，测试登录功能是否恢复正常，再逐一排查规则问题。

5. 应用池权限或进程模型问题 #

虽然你已设置应用池为非托管代码模式，但仍需确认：

• 应用池的运行账户是否拥有站点根目录的读写权限（.NET Core需要读写临时文件、缓存等）。
• 如果项目是32位编译，需在应用池设置中开启「启用32位应用程序」。

额外排查技巧 #

• 开启浏览器开发者工具，查看「Application」标签下的Cookie列表，确认登录请求后是否生成了认证Cookie。
• 在应用中增加详细日志：在Startup.cs中配置日志级别为Debug，查看认证过程的详细日志输出，定位具体失败环节：

services.AddLogging(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Debug);
});

内容的提问来源于stack exchange，提问作者Yunus KÖSE