{"id":8,"date":"2026-06-27T00:00:00","date_gmt":"2026-06-27T00:00:00","guid":{"rendered":"http:\/\/\/var\/www\/html\/?p=8"},"modified":"2026-07-21T01:02:30","modified_gmt":"2026-07-21T01:02:30","slug":"apache-htaccess-redirect-loop-500-internal-server-error","status":"publish","type":"post","link":"https:\/\/butitworkedlocal.com\/apache-htaccess-redirect-loop-500-internal-server-error\/","title":{"rendered":"Resolving Apache .htaccess Redirect Loop 500 Internal Server Error"},"content":{"rendered":"\n

Fix Apache .htaccess redirect loops causing 500 errors. Learn to troubleshoot mod_rewrite rules, canonical URLs, and SSL configurations to restore site access quickly.<\/strong><\/p>\n\n\n

A "500 Internal Server Error" originating from an .htaccess<\/code> redirect loop is a common, yet frustrating, issue for web administrators. It typically signifies a misconfigured mod_rewrite<\/code> rule that continuously redirects a request, causing the Apache server to exceed its internal redirect limit and eventually fail. This guide will walk you through diagnosing and resolving these persistent redirect loops, ensuring your website serves content correctly.<\/p>\n

Symptom & Error Signature<\/h3>\n

When an Apache .htaccess<\/code> redirect loop occurs, users will typically encounter one of the following in their web browser:<\/p>\n

    \n
  • HTTP 500 Internal Server Error:<\/strong> A generic error page indicating a server-side problem.<\/li>\n
  • ERR_TOO_MANY_REDIRECTS:<\/strong> Some browsers, like Chrome, explicitly report that the page isn't redirecting properly.<\/li>\n
  • "This page isn't working" \/ "Firefox has detected that the server is redirecting the request for this address in a way that will never complete."<\/strong>: Similar messages indicating a browser-level redirect limit was hit.<\/li>\n<\/ul>\n

    The definitive proof of a redirect loop resides in your Apache error logs. You'll typically find an entry similar to this:<\/p>\n

    [Sat Jun 27 10:30:00.123456 2026] [core:error] [pid 12345:tid 123456789] [client 192.168.1.100:54321] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel Debug' to get a backtrace.\n[Sat Jun 27 10:30:00.123456 2026] [core:error] [pid 12345:tid 123456789] [client 192.168.1.100:54321] AH00124: \/var\/www\/html\/index.php pcfg_openfile: unable to check access time of \/var\/www\/html\/index.php\n<\/code><\/pre>\n
    The AH00124<\/code> error code is the primary indicator of an internal redirect loop. The message might also point to the specific file being repeatedly requested, like index.php<\/code>.<\/p>\n
    Root Cause Analysis<\/h3>\n
    A redirect loop essentially means that a RewriteRule<\/code> in your .htaccess<\/code> file is continuously matching the URL it just<\/em> rewrote, or it's part of a cycle of two or more rules rewriting back and forth. This leads to an endless internal redirection chain until Apache's LimitInternalRecursion<\/code> (default 10) is hit, triggering the 500 error.<\/p>\n
    Common underlying reasons include:<\/p>\n
      \n
    1. Missing or Incorrect RewriteCond<\/code> (Rewrite Condition):<\/strong> Rules are applied indiscriminately without checking if the target condition (e.g., already HTTPS, already non-WWW) is met. This is the most frequent culprit.<\/li>\n
    2. Conflicting RewriteRule<\/code> Directives:<\/strong> Two or more rules that contradict each other, leading to an infinite cycle (e.g., A redirects to B, and B redirects back to A).<\/li>\n
    3. Improper Use of Flags ([L]<\/code>, [R]<\/code>, [NC]<\/code>, [OR]<\/code>):<\/strong>
        \n
      • Lack of [L]<\/code> (Last):<\/strong> Allows Apache to continue processing subsequent rules even after a match, potentially re-matching the same rule or a conflicting one.<\/li>\n
      • Incorrect [R]<\/code> (Redirect):<\/strong> Causes an external HTTP redirect instead of an internal rewrite, which can also loop if not properly conditioned.<\/li>\n<\/ul>\n<\/li>\n
      • RewriteBase<\/code> Misconfiguration:<\/strong> In subdirectory installations, an incorrect RewriteBase<\/code> can lead to URI mismatches, causing rules to re-evaluate incorrectly.<\/li>\n
      • Environment Mismatches (e.g., SSL offloading with proxies):<\/strong> When your website is behind a reverse proxy or load balancer that handles SSL, Apache might not see %{HTTPS}<\/code> as on<\/code>. If you then force HTTPS based on %{HTTPS}<\/code>, it will loop.<\/li>\n
      • Caching Issues:<\/strong> Less common for a 500 error, but browser or CDN caches can sometimes store faulty redirects, exacerbating testing.<\/li>\n
      • AllowOverride<\/code> Directive:<\/strong> While usually resulting in a 403 Forbidden or rules not being applied, if AllowOverride<\/code> is set to None<\/code> and an old browser cache still tries to apply a redirect, it could<\/em> contribute to confusion. However, for a 500 AH00124<\/code>, the .htaccess<\/code> file is<\/em> being read and processed.<\/li>\n<\/ol>\n
        Step-by-Step Resolution<\/h3>\n
        Follow these steps to diagnose and resolve the Apache .htaccess<\/code> redirect loop.<\/p>\n
        1. Backup Your .htaccess<\/code> File<\/h4>\n
        Before making any changes, always back up your current .htaccess<\/code> file. This allows you to revert to the original state if things go wrong or if you make an incorrect modification.<\/p>\n<\/blockquote>\n
        You can do this via SSH:<\/p>\n
        sudo cp \/var\/www\/html\/.htaccess \/var\/www\/html\/.htaccess.backup_$(date +%Y%m%d%H%M%S)\n<\/code><\/pre>\n
        2. Locate and Examine Apache Error Logs<\/h4>\n
        The Apache error logs are your primary source of information. On Debian\/Ubuntu systems, they are typically found here:<\/p>\n
        sudo tail -f \/var\/log\/apache2\/error.log\n<\/code><\/pre>\n
        Keep this terminal window open while you attempt to access your website. Look for the AH00124<\/code> error message. It may provide clues about the specific URL or file that's being repeatedly accessed.<\/p>\n
        3. Temporarily Disable mod_rewrite<\/code> or Comment Out Rules<\/h4>\n
        To quickly confirm if mod_rewrite<\/code> is indeed the cause, you can temporarily disable it or comment out all RewriteRule<\/code> and RewriteCond<\/code> directives.<\/p>\n
          \n
        1. Disable mod_rewrite<\/code> (less recommended for .htaccess<\/code> issues):<\/strong>\nThis requires root access and will affect all<\/em> mod_rewrite<\/code> rules on the server.<\/p>\n
          sudo a2dismod rewrite\nsudo systemctl restart apache2\n<\/code><\/pre>\n
          If your site loads (without redirects, potentially looking broken), mod_rewrite<\/code> was the issue. Re-enable with sudo a2enmod rewrite<\/code> after troubleshooting.<\/p>\n<\/li>\n
        2. Comment out .htaccess<\/code> rules (recommended):<\/strong>\nEdit your .htaccess<\/code> file (e.g., nano \/var\/www\/html\/.htaccess<\/code>) and place a #<\/code> at the beginning of every RewriteRule<\/code> and RewriteCond<\/code> line.<\/p>\n
          #RewriteEngine On\n#RewriteCond %{HTTPS} off\n#RewriteRule ^(.*)$ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n#RewriteCond %{HTTP_HOST} ^www.example.com [NC]\n#RewriteRule ^(.*)$ https:\/\/example.com\/$1 [L,R=301]\n<\/code><\/pre>\n
          Save the file and try accessing your site. If the 500 error disappears, the issue is definitely within your mod_rewrite<\/code> rules. Re-enable rules one by one or in small groups to pinpoint the problematic one.<\/p>\n<\/li>\n<\/ol>\n
          4. Analyze and Correct Common Redirect Loop Scenarios<\/h4>\n
          Once you've identified the problematic rule (or set of rules), apply the following common fixes:<\/p>\n
          Scenario A: HTTP to HTTPS Redirect Loop<\/h5>\n
          This is often caused by the RewriteCond %{HTTPS} off<\/code> not correctly detecting HTTPS when behind a reverse proxy or load balancer.<\/p>\n
          Problematic Example:<\/strong><\/p>\n
          RewriteEngine On\nRewriteCond %{HTTPS} off\nRewriteRule ^(.*)$ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
          If your server is behind a proxy that terminates SSL, Apache might still see requests as HTTP (%{HTTPS}<\/code> is off<\/code>), even though the user connected via HTTPS. The proxy typically sets an X-Forwarded-Proto<\/code> header.<\/p>\n
          Solution:<\/strong> Check for X-Forwarded-Proto<\/code> header.<\/p>\n
          # Correct HTTP to HTTPS redirect, handling proxies\nRewriteEngine On\nRewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]\nRewriteCond %{HTTPS} off\nRewriteRule ^(.*)$ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
          The [NC]<\/code> flag makes the condition case-insensitive. Adding %{HTTPS} off<\/code> as an OR<\/code> condition, or as a fallback, is also a robust approach for environments without proxies.<\/p>\n
          Scenario B: WWW to Non-WWW (or vice-versa) Redirect Loop<\/h5>\n
          Loops can occur when combined with HTTPS redirects, or if the rule isn't specific enough.<\/p>\n
          Problematic Example (forcing non-WWW):<\/strong><\/p>\n
          RewriteEngine On\n# Force non-WWW (might loop with HTTPS or other rules)\nRewriteCond %{HTTP_HOST} ^www.example.com [NC]\nRewriteRule ^(.*)$ http:\/\/example.com\/$1 [L,R=301]\n<\/code><\/pre>\n
          If you have a separate HTTP to HTTPS rule and then this one, they might conflict, e.g., https:\/\/www.example.com<\/code> -> http:\/\/example.com<\/code> (by this rule) -> https:\/\/example.com<\/code> (by HTTPS rule), leading to a loop.<\/p>\n
          Solution:<\/strong> Combine redirects and ensure conditions prevent self-matching.<\/p>\n
          # Combined HTTPS and non-WWW redirect (canonical URL)\nRewriteEngine On\nRewriteCond %{HTTP:X-Forwarded-Proto} !https [NC,OR]\nRewriteCond %{HTTPS} off [OR]\nRewriteCond %{HTTP_HOST} ^www.example.com [NC]\nRewriteRule ^(.*)$ https:\/\/example.com%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
          This single rule ensures all requests are sent to https:\/\/example.com<\/code>, removing both the www.<\/code> and forcing HTTPS in one go, preventing conflicts. Change example.com<\/code> to your domain.<\/p>\n
          Scenario C: Trailing Slash Issues<\/h5>\n
          Redirecting URLs to add\/remove trailing slashes can loop if not handled carefully, especially with DirectoryIndex<\/code> or file names.<\/p>\n
          Problematic Example:<\/strong><\/p>\n
          # Add trailing slash for directories (problem if target is already \/)\nRewriteCond %{REQUEST_FILENAME} -d\nRewriteRule ^(.*[^\/])$ $1\/ [R=301,L]\n<\/code><\/pre>\n
          Solution:<\/strong> Be specific and use conditions to avoid matching already correct URLs.<\/p>\n
          # Add trailing slash if a directory AND no slash exists\nRewriteCond %{REQUEST_FILENAME} -d\nRewriteRule ^(.*[^\/])$ \/$1\/ [R=301,L]\n\n# Or, remove trailing slash if not a directory (e.g. for clean URLs)\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteCond %{REQUEST_URI} (.+)\/$\nRewriteRule ^(.*)\/$ $1 [R=301,L]\n<\/code><\/pre>\n
          Scenario D: Index File Redirects (e.g., index.php<\/code> removal)<\/h5>\n
          If you're rewriting \/index.php<\/code> to \/<\/code>, ensure it doesn't then try to serve \/index.php<\/code> again implicitly.<\/p>\n
          Problematic Example:<\/strong><\/p>\n
          RewriteRule ^(.*)\/index.php$ \/$1\/ [R=301,L]\n<\/code><\/pre>\n
          If Apache's DirectoryIndex<\/code> is set to index.php<\/code>, requesting \/<\/code> will internally map to index.php<\/code>, which then matches this rule, leading to a loop.<\/p>\n
          Solution:<\/strong> Use conditions to avoid matching the base URL after the rewrite, or ensure your DirectoryIndex<\/code> is well-defined.<\/p>\n
          # Remove index.php from URL, but prevent loop on root\nRewriteCond %{THE_REQUEST} \/index.php [NC]\nRewriteRule ^(.*)index.php$ \/$1 [R=301,L,NC]\n<\/code><\/pre>\n
          %{THE_REQUEST}<\/code> matches the initial<\/em> request line, preventing internal rewrites from triggering the rule again.<\/p>\n
          5. Ensure [L]<\/code> (Last) Flag is Used Appropriately<\/h4>\n
          The [L]<\/code> (Last) flag is crucial. It tells mod_rewrite<\/code> to stop processing the current<\/em> set of rules if the RewriteRule<\/code> matches. Without it, subsequent rules in .htaccess<\/code> might re-evaluate the rewritten URL, potentially leading to a loop. Ensure all final redirect rules ([R=301]<\/code>) also include [L]<\/code>.<\/p>\n
          6. Verify AllowOverride<\/code> Directive<\/h4>\n
          For .htaccess<\/code> files to work, the AllowOverride<\/code> directive in your Apache virtual host configuration or apache2.conf<\/code> must permit it. If AllowOverride<\/code> is set to None<\/code> for the relevant directory, your .htaccess<\/code> rules will be ignored (often resulting in a 403 Forbidden or no redirect at all), but in some edge cases, it can cause unexpected behavior.<\/p>\n
          The AllowOverride<\/code> directive is configured in your main Apache configuration files, NOT in .htaccess<\/code>. Common locations are \/etc\/apache2\/apache2.conf<\/code> or in your site's virtual host configuration file (e.g., \/etc\/apache2\/sites-available\/yourdomain.conf<\/code>).<\/p>\n<\/blockquote>\n
          Open your virtual host configuration file:<\/p>\n
          sudo nano \/etc\/apache2\/sites-available\/yourdomain.conf\n<\/code><\/pre>\n
          Or the main Apache config:<\/p>\n
          sudo nano \/etc\/apache2\/apache2.conf\n<\/code><\/pre>\n
          Look for a <Directory><\/code> block corresponding to your website's root path (e.g., \/var\/www\/html<\/code>). Ensure AllowOverride<\/code> is set to All<\/code> or FileInfo<\/code>. FileInfo<\/code> is generally sufficient for mod_rewrite<\/code> rules.<\/p>\n
          <Directory \/var\/www\/yourwebsite>\n    Options Indexes FollowSymLinks\n    AllowOverride All   # Or AllowOverride FileInfo\n    Require all granted\n<\/Directory>\n<\/code><\/pre>\n
          If you modify your main Apache configuration, you'll need to restart Apache.<\/p>\n
          7. Test Configuration and Restart Apache<\/h4>\n
          After making any changes to .htaccess<\/code> or main Apache configuration, always test the syntax and restart the server.<\/p>\n
          sudo apache2ctl configtest\n<\/code><\/pre>\n
          You should see Syntax OK<\/code>. If not, review the error messages and correct them.<\/p>\n
          sudo systemctl restart apache2\n<\/code><\/pre>\n
          8. Clear Browser Cache<\/h4>\n
          Web browsers aggressively cache 301 (Permanent) redirects. If you've been testing faulty redirect rules, your browser might have cached the bad redirect, causing it to loop even after you've fixed the .htaccess<\/code> file.<\/p>\n<\/blockquote>\n
          After fixing your .htaccess<\/code> file and restarting Apache, clear your browser's cache completely, or use an incognito\/private browsing window to test. You can also use curl -I example.com<\/code> from the command line to see HTTP headers and verify redirects without browser caching.<\/p>\n
          curl -I https:\/\/example.com\ncurl -I http:\/\/www.example.com\n<\/code><\/pre>\n
          This will show you the exact HTTP response codes (e.g., HTTP\/1.1 301 Moved Permanently<\/code>) and the Location<\/code> header, indicating where the server is attempting to redirect.<\/p>\n
          By systematically applying these steps, you should be able to identify, correct, and resolve the Apache .htaccess<\/code> redirect loop leading to a 500 Internal Server Error.<\/p>\n","protected":false},"excerpt":{"rendered":"
          Fix Apache .htaccess redirect loops causing 500 errors. Learn to troubleshoot mod_rewrite rules, canonical URLs, and SSL configurations to restore site access quickly.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[19,3,14,17,15,6,20],"class_list":["post-8","post","type-post","status-publish","format-standard","hentry","category-web-server","tag-500-error","tag-apache","tag-htaccess","tag-mod_rewrite","tag-redirect-loop","tag-troubleshooting","tag-web-server"],"_links":{"self":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/8","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":2,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"predecessor-version":[{"id":256,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/8\/revisions\/256"}],"wp:attachment":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}