Let's work through this 502 error step by step—this is a super common gotcha with reverse proxy setups on RHEL, so I'll walk you through the most likely fixes:

1. Check SELinux Permissions (Most Common Culprit) #

RHEL 8 enables SELinux by default, and it blocks Nginx from making network connections to local services like your .NET Core app out of the box. Here's how to fix it:

• First, verify the current SELinux setting:

  getsebool -a | grep httpd_can_network_connect
  

• If the output shows httpd_can_network_connect --> off, enable it permanently (the -P flag makes this survive reboots):

  sudo setsebool -P httpd_can_network_connect on
  

• Then reload Nginx to apply the change:

  sudo nginx -s reload
  

This is the #1 reason I see 502s in RHEL/CentOS Nginx proxy setups.

2. Verify .NET Core Service is Listening Correctly #

Even though you tested curl http://localhost:5000 earlier, let's double-check the service is actually bound to the right port and accessible:

• Check which ports the dotnet process is listening on:

  sudo ss -tulpn | grep dotnet
  

• You should see output like LISTEN 0 128 127.0.0.1:5000 0.0.0.0:* users:(("dotnet",pid=XXXX,fd=XX))
• If it's listening on a different port, update your webapp3.service file's ExecStart line, then restart the service:

  sudo systemctl daemon-reload
  sudo systemctl restart webapp3.service
  

3. Check Nginx Error Logs for Exact Details #

Nginx's error log will tell you exactly why it can't connect to the backend. Let's dig into it:

• Tail the real-time error log in one terminal:

  sudo tail -f /var/log/nginx/error.log
  

• Run curl http://localhost in another terminal, then check the log. Common messages you might see:
  • connect() failed (13: Permission denied) while connecting to upstream → Confirms SELinux is blocking the connection (fix from step 1)
  • connect() failed (111: Connection refused) while connecting to upstream → The .NET Core service isn't running or listening on the expected port
  • upstream sent invalid response while reading response header from upstream → The backend is returning malformed data (check your .NET app's logs next)

4. Validate Nginx Proxy Configuration #

Your current proxy setup might have a path mismatch or missing headers causing issues:

• If your .NET app returns WeatherForecast data at the root (/), update your dotnetcore.conf to proxy directly to the root and add critical headers (these help the .NET app understand the original request):

  server {
      listen 80;
      server_name _;
      location / {
          proxy_pass http://localhost:5000/;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
      }
  }
  

• If you specifically want to proxy to /weatherforecast, double-check that endpoint exists in your .NET app! The default Web API template uses /WeatherForecast (capital W), and Linux is case-sensitive—this could cause a silent failure.
• After updating the config, test it and reload Nginx:

  sudo nginx -t
  sudo nginx -s reload
  

5. Confirm .NET Core Service is Still Running #

It's possible the service crashed since your initial test. Let's verify:

• Check the service status:

  sudo systemctl status webapp3.service
  

• Look for active (running) in the output. If it's failed, check the service logs to see what went wrong:

  sudo journalctl -u webapp3.service -f
  

This will show you any errors from the .NET app that might have caused it to crash.

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