ASP.NET Core 3应用部署NGINX反向代理后遇502错误求助

你的问题很典型——跨机器部署NGINX反向代理到Kestrel时遇到的连接拒绝问题，错误日志里的111: Connection refused已经给出了明确的方向，咱们一步步来排查解决：

1. 先验证最基础的网络连通性 #

在NGINX服务器（192.168.3.111）上直接测试到Kestrel服务器（192.168.3.222:5000）的端口连通性，这能快速定位是网络问题还是配置问题：

# 用curl测试能否访问Kestrel服务
curl http://192.168.3.222:5000

# 或者用telnet（未安装的话先执行sudo apt install telnet）
telnet 192.168.3.222 5000

如果这两步都返回“连接拒绝”，说明问题出在网络/防火墙/Kestrel监听配置，直接跳到步骤2；如果能正常返回网页内容，再检查NGINX的配置细节。

2. 确保Kestrel监听局域网可访问的地址 #

默认情况下，ASP.NET Core的Kestrel只会绑定127.0.0.1（仅本机可访问），这就是为什么你在Kestrel本机配置NGINX代理能正常工作，但跨机器不行。你需要修改Kestrel的监听地址：

方法1：通过Program.cs硬编码配置 #

在ASP.NET Core 3.x的Program.cs中添加UseUrls，指定监听所有IP（0.0.0.0）：

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
            // 允许所有IP访问5000端口
            webBuilder.UseUrls("http://0.0.0.0:5000");
        });

方法2：通过appsettings.json配置（更灵活） #

在appsettings.json中添加Kestrel端点配置：

{
  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://0.0.0.0:5000"
      }
    }
  }
}

修改后重启Kestrel服务，然后在Kestrel机器上执行以下命令确认监听地址：

sudo netstat -tulpn | grep :5000

输出应该显示0.0.0.0:5000（允许所有IP访问），而不是127.0.0.1:5000（仅本机访问）。

3. 确认Kestrel机器的防火墙规则生效 #

你提到已经开放了5000端口，但需要验证规则是否真正生效：

• 如果是Ubuntu系统（使用ufw防火墙）：

  # 查看当前防火墙规则
  sudo ufw status
  
  # 如果没有5000端口的规则，添加并重载
  sudo ufw allow 5000/tcp
  sudo ufw reload
  

• 如果是Windows系统（Kestrel运行在Windows上）：
  打开Windows Defender防火墙，确保“允许应用通过防火墙”中包含你的ASP.NET Core应用，或者手动添加5000端口的入站规则。

4. 优化NGINX配置的细节 #

你的NGINX配置整体没问题，但可以调整两个小细节避免潜在问题：

• 在upstream块中添加连接复用配置，提升性能：

  upstream dotnet { 
      zone dotnet 64k; 
      server 192.168.3.222:5000; 
      keepalive 32; # 添加这一行，启用长连接复用
  }
  

• 移除fastcgi_buffers和fastcgi_buffer_size配置项——这两个是给PHP-FPM服务用的，和ASP.NET Core反向代理无关，可能会导致不必要的配置冲突。

修改后重启NGINX：

sudo systemctl restart nginx

5. 确认ForwardedHeaders配置（避免后续重定向问题） #

你Startup.cs中的ForwardedHeaders配置是正确的，但要确保UseForwardedHeaders()在UseHttpsRedirection()之前调用（你已经做到了），这样Kestrel才能正确识别来自NGINX的HTTPS请求，避免错误的HTTP重定向。

完成以上步骤后，再次访问你的域名，应该就能正常连接到Kestrel服务了。

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