A 404 is not just “page not found.” In hosting environments, a 404 can come from the application, the web server, the control panel’s vhost orchestration, a CDN proxy layer, or even a misrouted domain that never reaches your site.
This guide is written for owners and admins who want to diagnose 404s properly — from the browser all the way down to the virtual host and filesystem.
Related guides (recommended):
- Linux command diagnostics in hosting environments
- Comparing Hosting Control Panels: Architecture, Security & Operational Tradeoffs
- What is Web Hosting? Detailed Overview
1) First: Confirm Which 404 You Are Seeing
There are multiple “404s” that look similar but have different causes.
A) Origin 404 (your server can’t find the resource)
This is the classic 404. The request reached your origin server, but the server (or app) could not locate the requested path.
B) CDN / proxy 404 confusion (the proxy is showing the origin’s response)
If you use a proxy like Cloudflare, it usually does not generate 404s for your site — it forwards the origin’s 404. That means the problem is still at the origin (routing, vhost, application, or filesystem).
Quick test: temporarily bypass the proxy (or test direct-to-origin) to confirm where the 404 is coming from.
C) Application-level 404 (WordPress, Laravel, Magento, etc.)
Sometimes the file exists and the web server is fine — the application decides the route does not exist.
This is common when:
- Rewrite rules are broken
- Permalinks are misconfigured
- The request reaches
index.php, but the router returns “Not Found”
2) The 404 Decision Tree (Fast Diagnosis)
Use this simple flow:
- Is it only one URL or the entire domain?
- One URL → likely missing file, wrong permalink, wrong rewrite, wrong case
- Entire domain → likely DNS/vhost/docroot mismatch
- Does the server return 404 for static files too? (e.g.,
/favicon.ico)
- Static also 404 → likely web server vhost/root/alias issue
- Static works but pages 404 → likely application routing/rewrite issue
- Is it intermittent?
- Intermittent 404s can indicate caching/CDN purge issues, multi-server mismatch, or vhost rebuild problems.
3) The Most Common Server-Level Causes (and How They Happen)
A) Wrong DocumentRoot (domain points to the wrong folder)
In control-panel hosting, domains are mapped to a DocumentRoot.
Common patterns:
- Primary domain uses
/home/user/public_html - Addon / subdomains use
/home/user/public_html/domain.com/or similar
If the DocumentRoot points to an empty directory, the server returns 404.
Symptoms:
- Entire domain returns 404
- Static files missing
Where this happens:
- Addon domain created incorrectly
- Domain moved/migrated and docroot not updated
- Panel vhost data not rebuilt after an error
B) Virtual host mismatch (wrong vhost catches the request)
If the Host header does not match any configured vhost, the request may fall into a default vhost.
Symptoms:
- The domain loads, but shows the wrong site or a generic 404
- Some domains on the server work, one does not
C) Case sensitivity (Linux vs dev machine)
Linux filesystems are case-sensitive.
/Image.jpgis different from/image.jpg
This commonly appears after deploying from a case-insensitive environment (Windows/macOS default) to Linux.
D) Permissions or security controls that look like a 404
Most permission problems return 403. However, certain web server configurations, security modules, or rewrite fallbacks can result in a 404-like outcome when access fails.
Also check MAC systems like SELinux if enabled.
4) Apache-Side 404 Causes (Shared Hosting Reality)
A) Broken .htaccess rules (rewrite loops or wrong rewrite base)
A single bad rule can cause WordPress or any CMS to return 404 for all routes.
B) Missing vhost entry after config issues (cPanel example)
If a domain’s vhost entry is missing from Apache configuration, the domain may not route to the correct DocumentRoot and can return errors when loading.
In such cases, rebuilding Apache config and restarting Apache can restore missing vhosts.
5) NGINX-Side 404 Causes (Reverse Proxy and Static Routing)
NGINX commonly returns 404 when:
A) root points to the wrong directory
The server looks in the wrong filesystem path.
B) try_files is misconfigured
try_files can force a 404 when fallbacks are wrong (for example, missing index.php fallback, missing query string pass-through).
C) alias vs root confusion
alias replaces the matching location prefix, while root appends the URI path. Misusing these with try_files often produces stubborn 404s.
6) WordPress 404s (The Most Common Application-Level Pattern)
If:
/wp-admin/works- the homepage works
- but posts/pages return 404
Then the web server is usually fine. The issue is typically:
- Permalink rewrite rules are not being applied
.htaccessrules are missing or blocked- NGINX rules are incomplete
In WordPress, a fast test is to re-save permalinks (without changing structure). But on managed hosting, you should confirm rewrites are actually being applied at the web server layer.
If performance plugins are involved, review our caching guide to avoid cache-layer confusion:
Evaluating WordPress Cache Plugins.
7) CDN and Caching Edge Cases
404s can be “real” but appear inconsistent due to caching:
- CDN caches a 404 for an old path
- You fix the origin, but the edge still serves cached 404
- Browser cache retains an old asset path
Rule: purge CDN and plugin cache when you deploy routing changes.
8) The Commands to Diagnose 404s (Bookmark Section)
If you have SSH access, these checks quickly pinpoint the layer.
A) Confirm which vhost is serving the domain
On Apache, list vhosts:
apachectl -S
Look for:
- the domain name
- the correct DocumentRoot
B) Test response headers and status
curl -I https://example.com/some/path
C) Tail web server error logs during a request
Apache:
tail -f /usr/local/apache/logs/error_log
NGINX (common paths):
tail -f /var/log/nginx/error.log
D) Confirm the file exists (and the path is correct)
ls -lah /home/USER/public_html/path/to/file
E) Trace rewrite decisions (advanced)
If .htaccess rewrite is suspected, error logs often reveal rewrite warnings. For deeper OS-level inspection (load, memory, disk I/O), use:
Linux command diagnostics in hosting environments.
9) Hosting Environment Notes (VPS vs Dedicated)
404 troubleshooting becomes harder when resources are constrained:
- High load can delay routing and make errors appear inconsistent
- Disk full conditions can break app caches and rewrite processing
If you operate on virtualized infrastructure, ensure the server has enough headroom:
10) Quick Fix Checklist (Safe and Practical)
Use this checklist in order:
- Confirm DNS points to the correct server
- Confirm the domain is mapped to the correct DocumentRoot
- Confirm vhost exists and matches the domain
- Confirm the file exists and path is correct (case-sensitive)
- Confirm rewrite rules are applied (WordPress permalinks /
.htaccess) - Purge caches (plugin + CDN)
- Check error logs while reproducing the request
Final Thoughts
A 404 is a routing signal. The fastest fix comes from correctly identifying where the “Not Found” decision is being made:
- CDN edge
- web server vhost
- rewrite rules
- filesystem
- application router
Once you treat 404s as a layered routing problem instead of a generic error, diagnosis becomes systematic — and much faster.
