Nginx部署Webpack编译的Node.js应用时部分资源无限加载求助

Hey there, let's break down why some resources are stuck in infinite loading after deploying your app—local tests working but production failing is super frustrating, so let's tackle this step by step.

First, I notice the Nginx config you shared only covers the HTTP-to-HTTPS redirect block. The real issue is likely hiding in your HTTPS server block (which you didn't include here), but let's go through all common culprits:

1. Misconfigured Static Resource Handling #

Webpack-compiled assets (JS, CSS, images, etc.) should be served directly by Nginx, not passed through to your Node.js server. If you're forwarding these requests to Node, it can cause bottlenecks, routing conflicts, or stalled responses.

Fix this by adding a location block in your HTTPS server config to serve static assets directly:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.beauteadom.me;

    # SSL cert configs go here...

    # Serve Webpack's compiled static assets directly
    location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff|woff2)$ {
        root /var/www/beauteadom.me/dist; # Replace with your actual Webpack output directory
        expires 30d; # Long cache for immutable assets
        add_header Cache-Control "public, immutable";
        add_header X-Content-Type-Options nosniff;
    }

    # Forward non-static requests to Node.js
    location / {
        proxy_pass http://beauteadom_me;
        # Critical headers for Node to handle requests correctly
        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;
        # Handle WebSockets if your app uses them
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

2. Incorrect Webpack publicPath Setting #

Local testing often works with relative publicPath, but production needs an absolute path to avoid broken resource URLs. Check your webpack.config.js:

module.exports = {
    // ... other configs
    output: {
        filename: '[name].[contenthash].js', // Add contenthash to bust cache
        chunkFilename: '[name].[contenthash].chunk.js',
        publicPath: '/', // Use absolute path (or CDN URL if you're using one)
        path: path.resolve(__dirname, 'dist') // Match this to the root in Nginx
    }
};

If publicPath is set to something like ./, browsers might request resources from the wrong directory (e.g., /some-page/main.js instead of /main.js), leading to stalled or failed requests.

3. Missing or Broken Reverse Proxy Headers #

If you're forwarding requests to Node.js without setting the right proxy_set_header values, your Node app might not respond correctly. For example, if your app checks the Host header or expects HTTPS, missing these headers can cause infinite redirects or hanging requests. The config in point 1 includes all essential headers—make sure they're present.

4. Browser Cache Conflicts #

Old cached assets from previous deployments can cause chaos. Using contenthash in your Webpack output filenames (as shown above) ensures each new build has unique asset URLs, so browsers don't load stale resources. Pair this with Nginx's cache headers to prevent unnecessary re-requests.

5. Check Nginx Logs for Clues #

When all else fails, look at the logs to see what's actually happening:

# View access logs to see request status codes
tail -f /var/log/nginx/access.log

# View error logs for server-side issues
tail -f /var/log/nginx/error.log

If you see 404s for the stuck resources, your static asset path is wrong. If you see 502 Bad Gateway, Node.js isn't running or Nginx can't reach it on port 3000.

Start by fixing the HTTPS server block and verifying your static asset paths—this is the most common fix for this exact issue.

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