HTTP 404 means the server could not find the resource at the requested URL. The right answer is to check the file path, the server config (nginx, Apache), the URL rewrites, and the SPA fallback. The mistake every team makes: the team sets the SPA fallback (try_files $uri /index.html) for every route, the team’s API routes (/api/*) return the index.html, the team’s app breaks in production. The right answer is to set the SPA fallback only for the non-API routes.
Table of contents
- The 404 status — what the server is saying
- The file path — the most common cause
- The server config — nginx and Apache
- The URL rewrites — the right answer for an SPA
- The SPA fallback — the one mistake that hides the API
- The static site generator — the right answer for a static-only site
- The 404 page — the right answer for a custom 404
- How this fits the rest of the stack
- FAQ
The 404 status — what the server is saying
HTTP 404 (Not Found) is the server’s response when the requested resource does not exist. The right answer for a static file is to check the file path on the server. The right answer for a dynamic route is to check the route’s handler. The right answer for an SPA is to check the rewrites and the fallback.
The file path — the most common cause
The most common cause of a 404 is the file path. The team typed /assests/image.png instead of /assets/image.png, the team is missing the file, the team has the wrong case (/Image.PNG vs /image.png on a case-sensitive filesystem). The right answer is to check the URL and the file path, the right answer is to use the browser’s DevTools Network tab to see the exact URL.
The server config — nginx and Apache
The right answer for a 404 on a static site is to check the server config. nginx: the root directive points to the static files directory, the try_files directive handles the fallback. Apache: the DocumentRoot directive points to the static files directory, the FallbackResource directive handles the fallback. The right answer is to test the config (nginx -t, apachectl configtest) before reloading.
The URL rewrites — the right answer for an SPA
The right answer for an SPA is URL rewrites. The team’s /users/123 route should return the index.html, the React Router handles the client-side routing. The right answer in nginx is try_files $uri /index.html (try the file, fall back to the index), the right answer in Apache is FallbackResource /index.html.
The SPA fallback — the one mistake that hides the API
The mistake: the team sets the SPA fallback for every route, the team’s API routes (/api/*) return the index.html, the team’s app breaks. The right answer is to set the SPA fallback only for the non-API routes. In nginx:
location /api/ {
# API routes: pass to the API server
proxy_pass http://api_upstream;
}
location / {
# SPA routes: fall back to index.html
try_files $uri /index.html;
}The right answer is to put the more specific location (/api/) before the general location (/). The right answer is to test the config with nginx -t before reloading.
The static site generator — the right answer for a static-only site
The right answer for a static-only site (Astro, Hugo, Jekyll) is to check the build output. The build generates the static files in dist/ (Astro), public/ (Hugo), _site/ (Jekyll). The right answer is to check the output directory, the right answer is to check the base config (Astro’s base: '/blog/' for a sub-path).
The 404 page — the right answer for a custom 404
The right answer for a custom 404 is a 404.html (or 404.astro for Astro) in the static files directory. The server returns the 404 status with the custom page, the team’s user gets a branded 404 instead of the server’s default. The right answer is to return the 404 status (not 200), the wrong answer is to return 200 with the 404 page (the team confuses search engines and the user).
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is HTTP 404?
The server’s response when the requested resource does not exist at the requested URL.
How do I fix a 404 on a static site?
Check the file path, the server config (nginx root, Apache DocumentRoot), the URL rewrites. Use the browser’s DevTools Network tab to see the exact URL.
How do I configure the SPA fallback in nginx?
location / { try_files $uri /index.html; } — try the file, fall back to index.html. Put the more specific location (/api/) before the general location.
How do I configure the SPA fallback in Apache?
FallbackResource /index.html in the .htaccess or the virtual host config.
How do I create a custom 404 page?
Create a 404.html (or 404.astro for Astro) in the static files directory. The server returns the 404 status with the custom page.
Why does my API return the index.html?
Because the SPA fallback is set for every route, including /api/*. Put the API location before the general location in the server config.
How do I debug a 404 in production?
Check the server logs (nginx error.log, the platform’s dashboard), the browser’s DevTools Network tab, the server config. Start with the URL, then the file path, then the server config.
What is the difference between 404 and 410?
404 means the resource is not found. 410 means the resource is gone permanently. The right answer is 404 for a missing file, 410 for a removed resource.