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

Troubleshoot and fix Apache 500 Internal Server Errors caused by infinite redirect loops in .htaccess files on Ubuntu 20.04 LTS servers.<\/strong><\/p>\n\n\n

When managing web servers, few issues are as frustrating and immediately impactful as a "500 Internal Server Error" due to an Apache .htaccess<\/code> redirect loop. This common problem indicates that your Apache server, specifically its mod_rewrite<\/code> module, is caught in an endless cycle of redirecting requests, eventually hitting an internal limit and failing. This guide provides a highly technical, step-by-step approach to diagnose and resolve this issue on an Ubuntu 20.04 LTS server running Apache 2.4.<\/p>\n

Symptom & Error Signature<\/h3>\n

Users attempting to access your website will typically encounter one of the following:<\/p>\n

    \n

  • Browser Output (Common):<\/strong><\/p>\n

      \n
    • "500 Internal Server Error"<\/li>\n
    • "ERR_TOO_MANY_REDIRECTS" (e.g., in Chrome)<\/li>\n
    • "The page isn't redirecting properly" (e.g., in Firefox)<\/li>\n
    • A blank white page, sometimes after a long loading time.<\/li>\n<\/ul>\n<\/li>\n

    • Apache Error Log Output (\/var\/log\/apache2\/error.log<\/code>):<\/strong>\nYou will likely see recurring entries indicating a redirect limit being exceeded. The exact message may vary slightly but will be similar to this:<\/p>\n

      [Timestamp] [proxy:error] [pid XXXX:tid YYYYYYYYYYY] (X) [client IP_ADDRESS:PORT] AH01144: 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[Timestamp] [core:crit] [pid XXXX:tid YYYYYYYYYYY] [client IP_ADDRESS:PORT] 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<\/code><\/pre>\n
      You might also see mod_rewrite<\/code> related debug messages if LogLevel<\/code> is increased:<\/p>\n
      [Timestamp] [rewrite:trace1] [pid XXXX:tid YYYYYYYYYYY] [client IP_ADDRESS:PORT] AH00666: [client IP_ADDRESS:PORT] (3) [main\/htaccess] applying pattern '^$' to uri '\/index.php'\n[Timestamp] [rewrite:trace1] [pid XXXX:tid YYYYYYYYYYY] [client IP_ADDRESS:PORT] AH00669: [client IP_ADDRESS:PORT] (3) [main\/htaccess] rewrite '\/index.php' -> '\/index.php'\n<\/code><\/pre>\n
      (Note: The AH01144<\/code> and AH00124<\/code> errors are critical indicators of a redirect loop.)<\/p>\n<\/li>\n<\/ul>\n
      Root Cause Analysis<\/h3>\n
      A 500 Internal Server Error caused by a redirect loop in .htaccess<\/code> primarily stems from mod_rewrite<\/code> rules that inadvertently create an infinite chain of redirects or rewrites. The underlying reasons typically fall into these categories:<\/p>\n
        \n
      1. Infinite Rewrite Loop:<\/strong> The most common culprit. A set of RewriteRule<\/code> or RewriteCond<\/code> directives are configured such that a request, after being processed by one rule, is then matched again by the same rule or another rule that effectively sends it back to a state where the first rule applies again. This cycle continues until Apache's internal redirect limit (defaulting to 10 for internal rewrites) is exceeded, leading to the 500 error.<\/p>\n<\/li>\n
      2. Incorrect RewriteBase<\/code> Directive:<\/strong> When .htaccess<\/code> files are used in subdirectories, RewriteBase<\/code> is crucial for correctly calculating the path for internal rewrites. An incorrectly set or missing RewriteBase<\/code> can cause mod_rewrite<\/code> to append the subdirectory path repeatedly, leading to an infinite loop as the URI keeps growing.<\/p>\n<\/li>\n
      3. Missing or Misplaced [L]<\/code> (Last) Flag:<\/strong> The [L]<\/code> flag tells mod_rewrite<\/code> to stop processing further RewriteRule<\/code> directives for the current request after a match. If this flag is omitted where needed, subsequent rules might re-evaluate the already rewritten URI, potentially sending it into a loop.<\/p>\n<\/li>\n
      4. Conflicting or Poorly Ordered Rules:<\/strong> When combining multiple redirect types (e.g., HTTP to HTTPS, www to non-www, adding\/removing trailing slashes), the order of the rules is paramount. If, for instance, a non-www to www rule redirects to HTTP, and an HTTP to HTTPS rule then redirects to HTTPS, but doesn't correctly handle the www\/non-www part, a loop can form.<\/p>\n<\/li>\n
      5. Proxy\/Load Balancer Awareness:<\/strong> If Apache is behind a reverse proxy or load balancer (e.g., Nginx, AWS ELB\/ALB), the mod_rewrite<\/code> rules for HTTPS detection (RewriteCond %{HTTPS} off<\/code>) might fail. The proxy terminates SSL and forwards requests to Apache via HTTP, making %{HTTPS}<\/code> always appear off<\/code>. This causes Apache to continually redirect to HTTPS, even if the user is already on HTTPS externally, creating a loop. The X-Forwarded-Proto<\/code> header is crucial here.<\/p>\n<\/li>\n
      6. Syntactic Errors in mod_rewrite<\/code> Directives:<\/strong> While less common for a redirect loop<\/em> and more for a general 500 error, malformed regular expressions or incorrect mod_rewrite<\/code> syntax can lead to unpredictable behavior, including loops if the engine misinterprets the rules.<\/p>\n<\/li>\n<\/ol>\n
        Step-by-Step Resolution<\/h3>\n
        Follow these steps meticulously to diagnose and resolve your Apache .htaccess<\/code> redirect loop.<\/p>\n
        1. Verify mod_rewrite<\/code> is Enabled and AllowOverride<\/code> is Set<\/h4>\n
        First, ensure the mod_rewrite<\/code> module is enabled and that Apache is configured to allow .htaccess<\/code> overrides for your web directory.<\/p>\n
          \n
        1. Check mod_rewrite<\/code> status:<\/strong><\/p>\n
          sudo apache2ctl -M | grep rewrite\n<\/code><\/pre>\n
          If rewrite_module<\/code> is not listed, enable it:<\/p>\n
          sudo a2enmod rewrite\nsudo systemctl restart apache2\n<\/code><\/pre>\n<\/li>\n
        2. Check AllowOverride<\/code> directive:<\/strong>\nThe Apache configuration for your virtual host or directory must permit .htaccess<\/code> overrides. Open your virtual host configuration file, typically located at \/etc\/apache2\/sites-available\/your-domain.conf<\/code> or the main Apache configuration \/etc\/apache2\/apache2.conf<\/code>.\nLocate the <Directory><\/code> block for your web root (e.g., \/var\/www\/html\/<\/code>):<\/p>\n
          <Directory \/var\/www\/html\/>\n    Options Indexes FollowSymLinks\n    AllowOverride All # This MUST be All\n    Require all granted\n<\/Directory>\n<\/code><\/pre>\n
          AllowOverride All<\/code> is crucial for .htaccess<\/code> files to be processed. If it's set to None<\/code> or not explicitly defined, your .htaccess<\/code> rules will be ignored or could lead to other issues. After modification, restart Apache:<\/p>\n<\/blockquote>\n
          sudo systemctl restart apache2\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
          2. Inspect Apache Error Logs for Clues<\/h4>\n
          The Apache error log is your primary source of diagnostic information. It will often explicitly state that a redirect limit has been exceeded.<\/p>\n
            \n
          1. Monitor the error log in real-time:<\/strong>
            sudo tail -f \/var\/log\/apache2\/error.log\n<\/code><\/pre>\n<\/li>\n
          2. Attempt to access the problematic URL<\/strong> in your browser.<\/li>\n
          3. Observe the log output.<\/strong> Look for messages similar to Request exceeded the limit of 10 internal redirects<\/code>. This confirms a rewrite loop. The log might also indicate the specific path being repeatedly rewritten.<\/li>\n<\/ol>\n
            3. Temporarily Disable the .htaccess<\/code> File<\/h4>\n
            To confirm that the .htaccess<\/code> file is indeed the source of the problem, temporarily disable it.<\/p>\n
              \n
            1. Navigate to your website's document root:<\/strong>
              cd \/var\/www\/html\/your-domain.com\/public_html\/ # Adjust path as necessary\n<\/code><\/pre>\n<\/li>\n
            2. Rename the .htaccess<\/code> file:<\/strong>
              mv .htaccess .htaccess_bak\n<\/code><\/pre>\n<\/li>\n
            3. Clear your browser cache<\/strong> (Ctrl+Shift+R or Cmd+Shift+R) and try accessing your site again.
                \n
              • If the site now loads (even without intended redirects), then the .htaccess<\/code> file is definitely the cause.<\/li>\n
              • If the site still shows a 500 error or doesn't load, the issue might be elsewhere (e.g., PHP error, server misconfiguration), but for this guide, we assume the .htaccess<\/code> is the culprit.<\/li>\n<\/ul>\n<\/li>\n
              • Once confirmed, proceed to analyze the .htaccess<\/code> contents.<\/strong> You can rename it back: mv .htaccess_bak .htaccess<\/code> before proceeding to the next step, or work on .htaccess_bak<\/code> directly and then rename it.<\/li>\n<\/ol>\n
                4. Analyze and Correct .htaccess<\/code> Rules<\/h4>\n
                This is the most critical step. You'll need to carefully review your .htaccess<\/code> file for common misconfigurations that lead to redirect loops.<\/p>\n
                Always back up your .htaccess<\/code> file<\/strong> before making any changes. A simple cp .htaccess .htaccess_backup_$(date +%Y%m%d%H%M%S)<\/code> will suffice.<\/p>\n<\/blockquote>\n
                Open your .htaccess<\/code> file for editing:<\/p>\n
                nano .htaccess # Or your preferred editor\n<\/code><\/pre>\n
                Focus on RewriteEngine On<\/code>, RewriteCond<\/code>, and RewriteRule<\/code> directives.<\/p>\n
                Common Pitfalls and Solutions:<\/strong><\/p>\n
                a. HTTP to HTTPS Redirect Loop (Especially with Load Balancers\/Proxies)<\/h5>\n
                This is a very common loop, often occurring when Apache is behind a proxy that handles SSL termination. Apache then sees requests as HTTP, and the .htaccess<\/code> repeatedly tries to redirect to HTTPS.<\/p>\n
                Incorrect (Common Error):<\/strong><\/p>\n
                # This can loop if Apache sees all requests as HTTP due to a proxy\nRewriteEngine On\nRewriteCond %{HTTPS} off\nRewriteRule ^(.*)$ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
                Corrected using X-Forwarded-Proto<\/code> (for proxy setups):<\/strong>\nIf your proxy sets X-Forwarded-Proto<\/code> (e.g., https<\/code>), use this header to detect the original protocol.<\/p>\n
                RewriteEngine On\nRewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]\nRewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
                If not behind a proxy and direct SSL:<\/p>\n
                RewriteEngine On\nRewriteCond %{HTTPS} off\nRewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
                b. WWW to Non-WWW (or vice versa) Redirect Loop<\/h5>\n
                Ensure your www\/non-www rules are correctly ordered, especially when combined with HTTPS redirects.<\/p>\n
                Incorrect (Potential Loop\/Conflict):<\/strong><\/p>\n
                # This rule might redirect to HTTP www, then HTTPS rule kicks in, then back to HTTP www...\nRewriteEngine On\nRewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]\nRewriteRule ^(.*)$ http:\/\/example.com\/$1 [L,R=301]\n<\/code><\/pre>\n
                Corrected (Non-WWW with HTTPS priority):<\/strong>\nIt's generally best to redirect to HTTPS first<\/em>, then handle www\/non-www.<\/p>\n
                RewriteEngine On\n\n# 1. Redirect HTTP to HTTPS\nRewriteCond %{HTTPS} off\nRewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n\n# 2. Redirect WWW to Non-WWW (only if the host starts with www.)\nRewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]\nRewriteRule ^ https:\/\/%1%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
                In this example:<\/p>\n
                  \n
                • The first rule ensures all traffic is HTTPS.<\/li>\n
                • The second rule assumes<\/em> the traffic is already HTTPS (or will be immediately redirected by the first rule) and then handles the www part. https:\/\/%1%{REQUEST_URI}<\/code> ensures it stays on HTTPS while removing www.<\/code>.<\/li>\n<\/ul>\n
                  c. Missing [L]<\/code> (Last) Flag<\/h5>\n
                  Always ensure redirect rules that should terminate processing have the [L]<\/code> flag. Without it, subsequent rules might apply to the already rewritten URI, leading to unintended behavior or loops.<\/p>\n
                  Example:<\/strong><\/p>\n
                  # Original rule potentially causing a loop if another rule re-processes the URI\nRewriteRule ^old-page.html$ \/new-page.html [R=301]\n\n# Corrected with [L] flag\nRewriteRule ^old-page.html$ \/new-page.html [L,R=301]\n<\/code><\/pre>\n
                  d. Incorrect RewriteBase<\/code><\/h5>\n
                  If your .htaccess<\/code> file is in a subdirectory (e.g., \/var\/www\/html\/blog\/.htaccess<\/code>), ensure RewriteBase<\/code> is set correctly.<\/p>\n
                  Example:<\/strong>\nFor \/var\/www\/html\/blog\/.htaccess<\/code>:<\/p>\n
                  RewriteEngine On\nRewriteBase \/blog\/ # Important for correct path calculation\nRewriteRule ^index.php$ - [L]\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule . \/blog\/index.php [L]\n<\/code><\/pre>\n
                  If your .htaccess<\/code> is in the document root (e.g., \/var\/www\/html\/.htaccess<\/code>), RewriteBase \/<\/code> is usually appropriate, or it can often be omitted if rules are relative to the root.<\/p>\n
                  e. Systematically Test Rules<\/h5>\n
                  If you have many rules, comment them out one by one (or in small groups) and test after each change to isolate the problematic rule(s).<\/p>\n
                  # RewriteEngine On\n# RewriteCond %{HTTPS} off\n# RewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n\n# This rule is currently active and being tested\nRewriteEngine On\nRewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]\nRewriteRule ^ https:\/\/%1%{REQUEST_URI} [L,R=301]\n<\/code><\/pre>\n
                  After testing, uncomment other rules gradually.<\/p>\n
                  5. Debug mod_rewrite<\/code> with LogLevel<\/code> (Advanced)<\/h4>\n
                  For deep debugging, you can temporarily increase Apache's LogLevel<\/code> for mod_rewrite<\/code>. This will produce extremely verbose output in your error log, showing how each rule is processed.<\/p>\n
                    \n
                  1. Open your main Apache configuration file<\/strong> (\/etc\/apache2\/apache2.conf<\/code>) or your virtual host file (\/etc\/apache2\/sites-available\/your-domain.conf<\/code>).<\/p>\n<\/li>\n
                  2. Locate the LogLevel<\/code> directive<\/strong> (usually LogLevel warn<\/code>) and add or modify it to include rewrite:traceN<\/code>, where N<\/code> is a number from 1 to 6 (6 being the most verbose). For Apache 2.4, trace1<\/code> through trace8<\/code> are available. trace5<\/code> or trace6<\/code> is usually sufficient for detailed rewrite debugging.<\/p>\n
                    LogLevel warn rewrite:trace5\n<\/code><\/pre>\n
                    Enabling rewrite:trace<\/code> generates an enormous amount of log data very quickly and can severely impact server performance and disk space. Do not use this on a production server for extended periods.<\/strong> Revert the LogLevel<\/code> immediately after debugging.<\/p>\n<\/blockquote>\n<\/li>\n
                  3. Restart Apache:<\/strong><\/p>\n
                    sudo systemctl restart apache2\n<\/code><\/pre>\n<\/li>\n
                  4. Access the problematic URL.<\/strong><\/p>\n<\/li>\n
                  5. Monitor the error log<\/strong> (sudo tail -f \/var\/log\/apache2\/error.log<\/code>). You will see detailed information about how mod_rewrite<\/code> processes each condition and rule. Look for patterns where a URI is repeatedly matched and rewritten by the same or a cyclical set of rules.<\/p>\n
                    Example log snippet you might see during a loop:<\/p>\n
                    [rewrite:trace2] [client 127.0.0.1:40830] rewrite 'index.php' -> 'index.php'\n[rewrite:trace2] [client 127.0.0.1:40830] add path info and hook 'index.php' to URI\n[rewrite:trace2] [client 127.0.0.1:40830] strip per-dir prefix: \/var\/www\/html\/index.php -> index.php\n[rewrite:trace2] [client 127.0.0.1:40830] applying pattern '^$' to uri 'index.php'\n[rewrite:trace2] [client 127.0.0.1:40830] rewrite 'index.php' -> 'index.php'\n[rewrite:trace2] [client 127.0.0.1:40830] add path info and hook 'index.php' to URI\n... repeated entries indicating a loop ...\n<\/code><\/pre>\n<\/li>\n
                  6. Once debugging is complete, revert the LogLevel<\/code><\/strong> to its original value (e.g., LogLevel warn<\/code>) and restart Apache.<\/p>\n<\/li>\n<\/ol>\n
                    6. Restore Configuration and Test<\/h4>\n
                    After implementing your corrected .htaccess<\/code> rules:<\/p>\n
                      \n
                    1. Ensure LogLevel<\/code> is reset<\/strong> in apache2.conf<\/code> or your virtual host file.<\/li>\n
                    2. Rename your .htaccess_bak<\/code> (if you used it for editing) back to .htaccess<\/code>:<\/strong>
                      mv .htaccess_bak .htaccess\n<\/code><\/pre>\n<\/li>\n
                    3. Restart Apache:<\/strong>
                      sudo systemctl restart apache2\n<\/code><\/pre>\n<\/li>\n
                    4. Clear your browser cache<\/strong> and test your website thoroughly, including different URLs and sections.<\/li>\n<\/ol>\n
                      By meticulously following these steps, you should be able to pinpoint and resolve the Apache .htaccess<\/code> redirect loop causing your 500 Internal Server Error on Ubuntu 20.04 LTS.<\/p>\n","protected":false},"excerpt":{"rendered":"
                      Troubleshoot and fix Apache 500 Internal Server Errors caused by infinite redirect loops in .htaccess files on Ubuntu 20.04 LTS servers.<\/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":[16,3,14,17,15,18],"class_list":["post-7","post","type-post","status-publish","format-standard","hentry","category-web-server","tag-500-internal-server-error","tag-apache","tag-htaccess","tag-mod_rewrite","tag-redirect-loop","tag-ubuntu-20-04"],"_links":{"self":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/7","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=7"}],"version-history":[{"count":2,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":255,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/posts\/7\/revisions\/255"}],"wp:attachment":[{"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/media?parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/categories?post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/butitworkedlocal.com\/wp-json\/wp\/v2\/tags?post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}