Let’s walk through the most common issues that might be preventing your manifest.json from being served properly— I’ve dealt with this exact scenario a few times, so here’s what to check:

1. Make Sure Nginx Reloaded Your Configuration #

It’s easy to forget this step, but Nginx won’t pick up new changes until you reload or restart it. Run these commands to confirm:

• Test your config for syntax errors first:

  sudo nginx -t
  

• If no errors show up, reload the service:

  sudo systemctl reload nginx
  

If nginx -t throws errors, fix those first— even a missing semicolon can break your entire config.

2. Verify Your location Block Is in the Right Context #

Your location /manifest.json rule needs to live inside the correct server block for your site. If it’s placed outside of a server block or in the wrong server context, Nginx won’t apply it. Here’s what a valid setup looks like:

server {
    listen 80;
    server_name yourdomain.com;

    # Other site configs (root, index, etc.) go here

    location = /manifest.json {
        default_type application/x-web-app-manifest+json;
    }
}

Notice I used location = /manifest.json (exact match) instead of just location /manifest.json— this ensures Nginx prioritizes this rule over any other JSON-related location blocks you might have.

3. Double-Check the mime.types Entry (and Whether You Even Need It) #

You added application/x-web-app-manifest+json webapp; to mime.types, but since you’re explicitly setting the MIME type in the location block, this entry might not even be used. That said:

• Confirm your nginx.conf includes the correct mime.types file with include mime.types; (usually pointing to /etc/nginx/mime.types).
• If you want to rely on mime.types instead of the location block, you could rename your manifest to site.webmanifest (the standard file extension for this MIME type) and Nginx would serve it correctly without extra location rules.

4. Rule Out Conflicting Location Rules #

If you have other location blocks that match .json files (like a regex rule location ~* \.json$), those might be overriding your manifest rule. Since regex locations have higher priority than non-exact prefix locations, switching to an exact match (as shown in step 2) will ensure your manifest rule takes precedence.

5. Test the Response Headers and File Validity #

Use curl to inspect the headers returned for your manifest:

curl -I https://yourdomain.com/manifest.json

Look for the Content-Type header— it should be application/x-web-app-manifest+json. If it’s not, your location rule isn’t being applied. If it is correct but the browser still doesn’t recognize the manifest:

• Check your browser’s dev tools console for JSON syntax errors in the manifest file itself. A missing comma or quote will break it, even with the right MIME type.
• If your manifest is served from a different origin than your site, add CORS headers to the location block:

  location = /manifest.json {
      default_type application/x-web-app-manifest+json;
      add_header Access-Control-Allow-Origin https://yourfrontenddomain.com;
  }
  

6. Check File Permissions #

Nginx runs as the www-data user (usually), so make sure it has read access to your manifest.json file:

sudo chown www-data:www-data /path/to/your/manifest.json
sudo chmod 644 /path/to/your/manifest.json

Also ensure the parent directories have at least 755 permissions so Nginx can traverse to the file.

内容的提问来源于stack exchange，提问作者David Dal Busco