Unhandled Runtime Errors

"How Do I...?"
1

Hello,
Could the Unhandled Runtime Errors error be related to Nginx configuration or directory permissions?
The Nginx configuration is:

server {
    listen 80;
    server_name localhost 127.0.0.1;
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    
    location / {
        # Don't process /branch requests here
        location /branch {
            # We'll handle this in the next section
        }
     location ~* ^/(\.git|\.env|\.svn|\.ht|wp-config\.php|boaform|admin|actuator) {
        deny all;
        return 404;
    }
        # Main proxy for root app
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        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;
        proxy_buffering off;
        proxy_request_buffering off;
    }
    # Static files for first app
    location /_next/static {
        proxy_pass http://127.0.0.1:3000/_next/static;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        expires 1y;
        add_header Cache-Control "public, immutable, max-age=31536000";
    }
    
    # =====================
    # Shared Backend API (Port 9000)
    # =====================
    location /api {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /var/www/public/index.php;
        include fastcgi_params;
        # Cache configuration
        fastcgi_cache PHP_CACHE;
        fastcgi_cache_valid 200 301 302 10m;
        fastcgi_cache_methods GET HEAD;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
        fastcgi_cache_min_uses 1;
        add_header X-Cache-Status $upstream_cache_status;
        # Headers
        fastcgi_param HTTP_HOST $host;
        fastcgi_param X-Real-IP $remote_addr;
        fastcgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
        # CORS
        add_header 'Access-Control-Allow-Origin' $cors_origin always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'X-Requested-With, Content-Type, Authorization' always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        if ($request_method = 'OPTIONS') {
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }
    # =====================
    # Error Handling
    # =====================
    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;
    location = /404.html {
        internal;
        root /usr/share/nginx/html;
    }
    location = /50x.html {
        internal;
        root /usr/share/nginx/html;
    }
}

After opening a few pages, the following error is displayed:

Unit (1)
Unit (1)1053×651 32.4 KB

What is your opinion?

Thank you.

1 Like
2

This specific error message strongly suggests a problem within the client-side JavaScript of your application, or the server-side application code itself (the one running on port 3000 or 9000) that is not properly catching exceptions.

It’s less likely to be a direct Nginx 404 or 500 error from Nginx itself because Nginx would typically return its own error pages (like your configured 404.html or 50x.html). The error message format looks like error output from the application. Take a look at the application logs.

While it is possible for the NGINX configuration to cause this runtime error, your configuration does not seem to show it as a direct cause.

Please note: This is my opinion and I am not an NGINX guru.

Hope this helps

davemc

2 Likes
3

Hello,
Thank you for your guidance.
How can I configure Nginx to show an error if it is related to the configuration?

4

If your NGINX configuration is outright wrong, you will easily know since trying to reload NGINX with the configuration will fail, and you will get an error message on your terminal. You can also easily check if the NGINX configuration is valid by running nginx -t before reloading with nginx -s reload.

If, however, the configuration works and you are running into a runtime error, the easiest option is to check the NGINX error logs. The default location is /var/log/nginx/error.log. The error_page directive is useful to get a visible page when you run into a 40x/50x error but its not the best way to debug NGINX errors.

1 Like
5

Hello,
The Nginx configuration is clean and running fine. When the Unhandled Runtime Errors occur, no errors are logged in the /var/log/nginx/error.log file.

6

The error you are seeing in the screenshot you provided is quite likely a JS error. Something in next.js is crashing. Seems like it’s likely to be Webpack?

1 Like
7

Hello,
Could it be because the project has not been built and is under development?

8

It could be? My gut feeling is that some file or some callback is referencing an invalid path, but you are more likely to get more/better insights/help if you post on the next.js GitHub repo. I don’t think any of us here are JS experts, and next.js is a server side react implementation which is quite niche even within the react world.

1 Like