部署至Ubuntu的.NET Core WebAPI遇Nginx连接拒绝及HTTP 500错误求助

Since your WebAPI works locally but throws a 500 error with Nginx logging connect() failed (111: Connection refused), the core issue is that Nginx can’t reach your Kestrel server. Let’s walk through the most common fixes step by step:

1. Verify your Kestrel service is running #

Start by checking if the systemd service for your app is active and healthy:

systemctl status kestrel-project.service

If it shows failed or inactive, pull the service logs to find exactly why Kestrel isn’t launching—this is usually the fastest way to spot issues:

journalctl -u kestrel-project.service -f

Look for red flags like missing dependencies, incorrect file paths in your service file, or port binding failures.

2. Confirm Kestrel’s listening port matches Nginx’s proxy target #

Double-check two critical points here:

• In your Program.cs, ensure Kestrel is listening on the port you expect. For example:

  builder.WebHost.ConfigureKestrel(options =>
  {
      options.ListenAnyIP(5000); // Make sure this port matches what's in Nginx
  });
  

• In your Nginx config (/etc/nginx/sites-available/default), verify the proxy_pass points to the same port:

  location / {
      proxy_pass http://localhost:5000; // Must match Kestrel's listening port
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection keep-alive;
      proxy_set_header Host $host;
      proxy_cache_bypass $http_upgrade;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
  }
  

If these don’t align, Nginx will fail to connect every time.

3. Check if the target port is in use #

Another common culprit is a conflicting process hogging the port Kestrel is supposed to use. Run this to check:

ss -tulpn | grep :5000 # Replace 5000 with your actual port

If you see another process ID (PID) listed, either kill that process or update Kestrel to listen on a different port.

4. Test Kestrel directly on the server #

Bypass Nginx entirely to confirm if the WebAPI itself is functional on the server. Run a local curl request:

curl http://localhost:5000/api/your-test-endpoint

If this returns a 500 error, the problem lies with your WebAPI (not Nginx). Check the Kestrel logs (via journalctl) for details—common issues here include missing appsettings.json values, broken database connections, or permission issues accessing files/resources.

5. Validate Nginx configuration and restart #

Make sure your Nginx config has no syntax errors:

nginx -t

If it passes, restart Nginx to apply any changes you’ve made:

systemctl restart nginx

Also confirm your soft link is correctly set up (sometimes links break during updates):

ls -l /etc/nginx/sites-enabled/default

It should point directly to /etc/nginx/sites-available/default.

6. Check file permissions for your WebAPI #

If Kestrel is running under a non-root user (which is recommended), ensure that user has read access to your project files, configs, and any required resources. For example, if using www-data:

chown -R www-data:www-data /path/to/your/webapi/project

Start with step 1—most of the time, the Kestrel service has failed to start for a simple reason like a typo in the service file or a missing dependency. Once you get Kestrel running and reachable locally on the server, Nginx should start proxying requests correctly.

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