If you're trying to rewrite clean URLs like <code>/results/summer-meet</code> to <code>/results/view.php?slug=summer-meet</code> in Nginx, everything might seem simple... until your <code>.php</code> files start downloading instead of executing.Here’s what’s going wrong — and how to fix it.<figure class="image"><img src="https://images.unsplash.com/photo-1613905780946-26b73b6f6e11?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxzdHVwaWR8ZW58MHx8fHwxNzQ3MjczMDY0fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@elimendeinagella?utm_source=DNX&amp;utm_medium=referral">Elimende Inagella</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>❌ The Common (Broken) Approach Using Regex</h2><pre><code class="language-plaintext">location ~ ^/(results|standards|meet|heat-sheets|psych-sheets)/ {
 try_files $uri $uri/ @rewrite_view;
}

location @rewrite_view {
 rewrite ^/(results|standards|meet|heat-sheets|psych-sheets)/([a-z0-9\-]+)$ /$1/view.php?slug=$2 last;
}
</code></pre>Why it fails:The <code>location ~</code> block is a regex match.Nginx gives regex blocks higher priority, and once it matches this block, it does not fallback to your global <code>.php</code>handler like:<pre><code class="language-plaintext">location ~ \.php$ { ... }
</code></pre>Result: <code>/results/view.php</code> gets matched by the regex block, and since there's no <code>.php</code> handler inside, Nginx serves it as a static file — or downloads it.<h2>✅ Working Alternative (Split Routers, No Regex)</h2>The safest way is to avoid regex and use one <code>location</code> per folder:<pre><code class="language-plaintext">location /results/ {
 try_files $uri $uri/ @rewrite_results;
}

location @rewrite_results {
 rewrite ^/results/([^/]+)$ /results/view.php?slug=$1 last;
 return 404;
}
</code></pre>Repeat for each folder (<code>/standards/</code>, <code>/meet/</code>, etc.).This works because:<code>location /results/</code> is a prefix match, not regexIf the file exists (like <code>view.php</code>), it falls through to the global <code>.php$</code> handler correctlyNo more downloads. Clean, clear routing.<h2>✅ Advanced Fix: Keep Regex Router + Add Folder-Specific <code>.php</code> Handler</h2>If you really want to keep the compact regex style, you must re-define <code>.php</code> handling for those folders:<pre><code class="language-plaintext">location ~ ^/(results|standards|meet|heat-sheets|psych-sheets)/ {
 try_files $uri $uri/ @rewrite_view;
}

location ~ ^/(results|standards|meet|heat-sheets|psych-sheets)/.*\.php$ {
 include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.2-fpm-swimsnap.sock;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;
}
</code></pre>This ensures PHP files inside those folders (like <code>view.php</code>) still get routed through PHP-FPM correctly.<h2>🧠 Final Advice</h2>Prefer prefix-based blocks (<code>location /results/</code>) unless you have a strong reason for regexIf you use <code>location ~</code>, you must handle <code>.php</code> within the same scope or via more specific regexAlways verify with <code>nginx -t</code> and test <code>.php</code> execution directly to avoid silent errorsIf you're seeing downloads or blank responses, chances are it's not your rewrite — it's Nginx falling into the wrong block.

This post explains why Nginx PHP rewrites using regex-based location ~ blocks often fail — causing .php files to download instead of execute. It walks through a reliable no-regex solution using prefix-based locations and shows how to fix the regex approach by adding folder-specific .php handlers. Ideal for anyone implementing clean URLs in PHP with Nginx.

All Posts In Rewrite