在 NGINX 代理后面的 Ubuntu 上运行的 .NET Core 2.2 Web 应用程序中看不到错误原因

Question

I have an Ubuntu server running NGINX as a reverse proxy to an ASP.NET Core 2.2 web API, and I am having trouble diagnosing a 500 server error I keep getting on requests to the API.

I have looked through all the logs I can see in /var/logs, the application logs which are set to trace, and the nginx error logs which are set to debug. However there is no clue about where the error lies.

All requests to the API are failing with the same 500 response, except for one which is the IdentityServer authentication token endpoint which does work. That is running in the same API.

I suspect the issue may be early in the request pipeline, before it comes into my controller actions.

There is a SQL Server database on the server but it is not being accessed for the particular requests I am trying so I am ruling that out.

My question is where else can I look to see what is going on? It must be something related to the application as that is the only thing that has changed, and another site running behind NGINX on the same machine is working fine so I'm not blaming the NGINX config.

When I revert the whole server to a backup before the deployment was done, everything runs fine. The deployment of the application code breaks something but I just can't find out what or why.

The 500 error response is very plain without the usual headers. NGINX has been configured to add a lot more response headers than this.

 HTTP/1.1 500 Internal Server Error Server: nginx Date: Thu, 05 Mar 2020 21:12:54 GMT Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=30

Answer 1

The problem was with some code inside a constructor that was being called during application startup during dependency injection instantiation.

There was no problem while developing locally with 'dotnet run', but when publishing the files in Debug or Release mode, then it threw an exception.

The error was found after adding this line to the Startup.Configure method:

 app.UseDeveloperExceptionPage();

This enabled me to see the error clearly straight away. This error was not seen in any other logs, and the error only occurred when running published files, hence the difficulty in diagnosing the problem.