博客 (260)

ASP.NET 10 网站在 VS 中运行正常，发布到 IIS 后，某个页面打开报 500 错误，在 Action 中整个套上 try-catch 捕获不到错误，怎么才能查看这个异常原因？

最直接的方法是：在 Windows 中打开“事件查看器”，导航到“Windows 日志” -> “应用程序”，查找来源为 IIS AspNetCore Module、.NET Runtime 或 IIS Express AspNetCore Module 的错误事件。

当然你也可以在 IIS 管理器中配置对应网站的错误页，或在 Program.cs 中启用了开发者异常页面，但是非常不建议在开发环境中开启这些。

ASP.NET 网站项目发布到远程 IIS，报错：

Web 部署任务失败。(已使用指定的进程(“Web Management Service”)连接到远程计算机，但未能验证服务器的证书。如果你信任该服务器，请再次连接并允许不信任的证书。  在以下位置了解更多信息: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED。) ...

参照错误信息中的网址，在项目文件中添加该配置：

<PropertyGroup>
  <AllowUntrustedCertificate>true</AllowUntrustedCertificate>
</PropertyGroup>

问题复现

使用 .NET Framework 开发的网站项目，用 QQ 浏览器访问无法登录成功，用其它浏览器（如 Edge）没有问题。

只有访问 https 地址时出现问题。

原因

在 HTTPS 协议下，现代浏览器（特别是 QQ 浏览器）会强制执行安全策略。根据规范，当 Cookie 设置了 SameSite=None 时，必须同时设置 Secure 属性，否则浏览器会静默拒绝（丢弃）该 Cookie。

解决方案

方法一：如果您是通过 web.config 配置的，请确保 <system.web> 节点下的 <httpCookies> 设置正确，并且您的 .NET Framework 版本支持这些属性（4.7.2+）。

<system.web>
    <httpCookies sameSite="None" requireSSL="true" />
    <sessionState ... />
</system.web>

方法二：在 Global.asax 文件的 Application_PostAuthenticateRequest 或 Application_EndRequest 事件中，强制为 Cookie 添加 Secure 属性。

protected void Application_PostAuthenticateRequest(object sender, EventArgs e)
{
    // 仅在 HTTPS 环境下处理
    if (Request.IsSecureConnection)
    {
        HttpCookie sessionCookie = Response.Cookies["ASP.NET_SessionId"];
        if (sessionCookie != null)
        {
            // 强制设置 SameSite=None 和 Secure
            sessionCookie.SameSite = SameSiteMode.None;
            sessionCookie.Secure = true; 
            Response.Cookies.Set(sessionCookie);
        }
    }
}

检验

确认 Set-Cookie 的值变为：

ASP.NET_SessionId=...; path=/; HttpOnly; SameSite=None; Secure

方法一：打开 事件查看器-> Windows 日志-> 应用程序。

方法二：启用ASP.NET Core Module Stdout 日志。

修改网站根目录下的 web.config 文件，在 <aspNetCore> 节点中启用标准输出日志。你需要先手动创建 logs 文件夹并确保有写入权限。

<aspNetCore processPath="dotnet" 
            arguments=".\YourAppName.dll" 
            stdoutLogEnabled="true" 
            stdoutLogFile=".\logs\stdout" 
            hostingModel="inprocess" />

重现错误后，即可在 logs 目录下查看生成的日志文件。注意：出于性能考虑，问题解决后建议将 stdoutLogEnabled 设为 false。

今天发现在 .NET Framework 和 .NET 9 中使用 System.Uri.EscapeDataString() 方法对字符串进行编码，会产生不同的结果。

譬如“(”符号，前者视其为非保留字符，不进行转义，后者视为保留字符，转义为“%28”。

原因是 .NET Framework 4.8 主要遵循 RFC 2396，而 .NET 9 遵循 RFC 3986。

在跨平台签名验证场景中，对 URL 编码的一致性要求极高，任何细微差别都会导致签名校验失败。

以下是以 RFC 3986 标准为核心、优先使用各平台内置的高一致性方案。

对于 .NET 9，直接使用 Uri.EscapeDataString()。

string encodedData = System.Uri.EscapeDataString(dataToEncode);

对于 .NET Framework，以下是一个遵循 RFC 3986 严格标准的自定义编码方法示例。

static string Rfc3986EscapeDataString(string input)
{
    // 定义 RFC 3986 中明确的未保留字符集（不编码）
    var unreservedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";

    var result = new StringBuilder();
    byte[] data = Encoding.UTF8.GetBytes(input); // 统一转换为 UTF-8 字节

    foreach (byte b in data)
    {
        char currentChar = (char)b;
        // 如果是未保留字符，直接输出
        if (unreservedChars.IndexOf(currentChar) != -1)
        {
            result.Append(currentChar);
        }
        else
        {
            // 否则，进行百分号编码（%XX，大写）
            result.Append('%').Append(b.ToString("X2"));
        }
    }
    return result.ToString();
}

对于 PHP，直接使用内置的 rawurlencode() 函数。这个函数的设计初衷就是严格遵循 RFC 3986 标准。

$encoded_data = rawurlencode($data_to_encode);

对于 JavaScript，encodeURIComponent 函数严格遵循 RFC 3986 标准。

let encodedData = encodeURIComponent(dataToEncode);

重要提示：无论使用哪种语言，务必在编码前明确指定字符串使用 UTF-8 编码。编码不一致是导致乱码和签名失败最常见的原因之一 。

今天遇到一个向基于 .NET Framework 框架开发的 Web 网站 POST 数据响应 405 Method Not Allowed 的问题。

服务端接口地址是 https://***/api/abc/Default.aspx，

若请求 https://***/api/abc/Default.aspx 或 https://***/api/abc/ 则正常 ，

若请求 https://***/api/abc 就会出现这个问题。

原因可能是服务器可能返回 301 重定向到 https://***/api/abc/Default.aspx，

导致最终接口接受到的请求方法不是 POST 。

确保已正确配置环境网站项目。

-----------------------------------------

2025/11/3 启动失败，查到项目日志过大（位于 F:\www\wwwlogs\net），清除后正常启动。

-----------------------------------------

不定时更新。

在 Linux 上运行 .NET 网站，通过

HttpContext.Connection.RemoteIpAddress

获取客户端的 IP 地址，结果是

::ffff:127.0.0.1

解决方法：

打开 Program.cs 文件，在 var app = builder.Build(); 之前（尽量往前）添加以下代码：

if (OperatingSystem.IsLinux())
{
    builder.Services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders = ForwardedHeaders.XForwardedFor
                                    | ForwardedHeaders.XForwardedProto
                                    | ForwardedHeaders.XForwardedHost;

        // 清除 KnownNetworks 和 KnownProxies，表示信任来自本机的代理（如 Nginx）
        options.KnownNetworks.Clear();
        options.KnownProxies.Clear();
    });

    Console.WriteLine("ForwardedHeaders enabled (Running on Linux)");
}

然后在 app.UseRouting(); 之前添加以下代码：

if (OperatingSystem.IsLinux())
{
    app.UseForwardedHeaders();
    Console.WriteLine("UseForwardedHeaders() applied.");
}

其中，OperatingSystem.IsLinux() 用于判断只在 Linux 环境中生效，你可以视自身情况作判断。

.NET 项目发布到 Linux / CentOS / nginx 上，调用 RedirectToAction 方法跳转到 127.0.0.1:443，而不是正在访问的域名，怎么办？

打开该网站的 nginx 配置文件，找到反射代理配置（proxy_pass），将：

proxy_set_header Host 127.0.0.1:$server_port;

改为

proxy_set_header Host $host;