.NET Core 3.1 Web API部署Nginx：HTTP正常HTTPS POST报500错误排查

首先，从你的Nginx错误日志和配置细节来看，核心问题其实是HTTPS代理块的配置犯了一个常见错误——循环请求，这直接导致了500错误和文件句柄耗尽的问题；后续的400错误则是连锁反应，我们一步步拆解解决：

1. 紧急修复：搞定Nginx循环代理的致命问题 #

你的HTTPS server块里写了proxy_pass https://127.0.0.1;，这可是个大坑：

• 你的Kestrel服务器不管是开发还是生产环境，都只监听http://127.0.0.1:5000的HTTP请求（从launchSettings.json也能看出来），根本没开443端口的HTTPS服务。
• 当Nginx接到HTTPS请求后，你让它代理到https://127.0.0.1，默认会去连443端口——而这个端口正好是Nginx自己在监听的HTTPS端口！这就形成了Nginx无限请求自己的死循环，瞬间把服务器的文件句柄耗尽，自然就报Too many open files和500错误了。

修复方法超简单： #

把HTTPS server块的proxy_pass改成和HTTP服务器一样的目标就行：

proxy_pass http://127.0.0.1:5000;

别担心HTTP不安全——Nginx已经帮你处理了客户端的HTTPS加密，它和后端Kestrel用HTTP通信是反向代理的标准操作，完全没问题。

2. 补全文件句柄限制配置（防患未然） #

就算修复了循环，高并发场景下文件句柄不够还是可能出问题，得把系统和Nginx的配置配到位：

• 在nginx.conf里把worker_rlimit_nofile设得比worker_connections大一点，比如：

  worker_rlimit_nofile 20000; # 你的worker_connections是16384，设20000足够
  

• 修改系统对www-data用户的文件句柄限制：编辑/etc/security/limits.conf，加上两行：

  www-data soft nofile 20000
  www-data hard nofile 20000
  

• 调整内核的全局文件句柄上限：编辑/etc/sysctl.conf，加一行：

  fs.file-max = 65535
  

  执行sysctl -p让配置生效。

3. 解决400错误：请求头/ Cookie过大的问题 #

你改了文件句柄后出现400，大概率是请求头大小超过了Nginx或Kestrel的限制，两边都要调整：

3.1 Nginx端的缓冲配置 #

别在http块和server块重复设置large_client_header_buffers，容易冲突。建议在nginx.conf的http块统一设成更大的值：

large_client_header_buffers 4 32k; # 每个缓冲32KB，总共4个，足够应对大部分大请求头

3.2 Kestrel端的请求头限制 #

.NET Core的Kestrel默认把请求头总大小限制在32KB，如果你的请求带了大Cookie或者自定义头，很容易触发400。在Program.cs里放宽这个限制：

var builder = WebApplication.CreateBuilder(args);

// 给Kestrel加配置，调整请求头总大小
builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxRequestHeadersTotalSize = 65536; // 改成64KB，按需调整
});

// 其他原有配置...
var app = builder.Build();

4. 优化ForwardedHeaders：让应用识别真实的HTTPS请求 #

你已经加了app.UseForwardedHeaders()，但还得告诉Kestrel要信任Nginx传递的头信息，不然应用可能以为请求是HTTP的，导致后续逻辑出问题。在Program.cs里补充配置：

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = 
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // 信任来自Nginx本地地址的头
    options.KnownProxies.Add(IPAddress.Parse("127.0.0.1"));
});

注意这段代码要放在builder.Build()之前哦。

5. 验证Kestrel的监听状态（彻底排除疑虑） #

为了确认Kestrel确实在正常监听5000端口，在服务器上执行命令：

sudo lsof -i :5000
# 或者用netstat：
sudo netstat -tulpn | grep 5000

如果输出里能看到dotnet进程监听127.0.0.1:5000，那就说明监听没问题。

最后一步：重启测试 #

1. 重启Nginx：sudo systemctl restart nginx
2. 重启你的.NET应用：sudo systemctl restart [你的应用服务名]
3. 用Postman测HTTPS请求，应该就能正常返回200了；同时去看Nginx的错误日志，确认没有新的报错。

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