Redirect loop on multiple sites with 1.25 (1.24)

[mathiasoem]

Version

1.25

What did you expect to happen?

Site not ending in a redirect loop.

What actually happens?

After upgrading a bunch of sites from 1.22 to 1.25 (pretty sure it also happens on 1.24) a lot of them are experiencing redirect loops.
The location header is the exact same url as the visited url. X-redirected-by = wordpress.

As far as i can tell it is caused by the fastcgi cache. When using query params or disabling the cache the issue is gone.
If the site is left alone, it start working again after 60 minutes. The only other thing that solves the issue is a deployment. (provisioning / restarting the server has no effect)

Unfortunately i have no idea how to debug this further, but i hope that some one can lead me in the right direction to figure this out.

Steps to reproduce

Provision and deploy a site with 1.25 that was previously 1.22. Not all of our sites are affected though.

System info

There doesn't seem to be any commonalities between the affected sites. They are on different ubuntu, php and nginx versions.

Log output

Please confirm this isn't a support request.

Yes

[blydewright]

I experience a similar/same issue and have isolated to only occuring when microcaching is active on the site. It also doesn't occur continuosly, but roughly once per day. Only a new deployment resolves the redirect loop until it reoccurs again on it's own. It also only applies to the home page (examplesite.com/).

@mathiasoem any commonalities between my experience and yours? Does the problem still occur when microcaching is disabled?

[mathiasoem]

@blydewright Yep. That sounds like the same issue. Wondering if it hast something to do with Wordpress not recognizing the request as being https and there trying to redirect.

[blydewright]

@mathiasoem is microcaching enabled or disabled for your sites? If enabled, what happens when you disable it? Does the problem go away?

[blydewright]

I am currently testing out an nginx override where fastcgi (provides microcaching) only caches 200 page responses. With the help of GPT5, I've been led to believe that this could be as a result of a WP transient caching the redirect which has a longer TTL than a normal page TTL. I'll paste the relevant chat excerpt below. Lets see if it works by testing for a day or 2.

Here is the override (using a child template in trellis/nginx-includes/production/wordpress-site.conf.child)

{% extends 'roles/wordpress-setup/templates/wordpress-site.conf.j2' %}

{% block cache_config -%}
  {% if item.value.cache is defined and item.value.cache.enabled | default(false) -%}
  fastcgi_cache wordpress;
  fastcgi_cache_valid 200 {{ item.value.cache.duration | default(nginx_cache_duration) }};
  fastcgi_cache_bypass $skip_cache;
  fastcgi_no_cache $skip_cache;
  fastcgi_cache_background_update {{ item.value.cache.background_update | default(nginx_cache_background_update) }};

  {% endif -%}
{% endblock -%}

The "200" after fastcgi_cache_valid is the only change to the block, copied from trellis/roles/wordpress-setup/templates/wordpress-site.conf.j2.

My current wordpress_sites.yml cache settings are:

cache:
      enabled: true
      duration: 60s
      skip_cache_uri: /wp-admin/|/wp-json/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml
      skip_cache_cookie: comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in

Here is the GPT5 thread:

Likely root cause:

A transient (very short-lived) redirect is emitted once per day only for / (home) by WordPress (plugin/theme/canonical logic/cron).
Nginx FastCGI microcache captures that 301 and serves it.
The 301 is cached with a longer TTL (≈3600s) than your normal page TTL, so the home page loops for exactly 1 hour.
Redeploy/provision flushes/removes the FastCGI cache so the site recovers immediately.
Why 1 hour when duration: 60s? In Trellis, cache.duration affects 200 responses (and only when cache.enabled: true). If a custom or default fastcgi_cache_valid directive elsewhere (either in Trellis defaults or an override you added previously) sets a longer validity for 301 (common patterns: fastcgi_cache_valid 301 302 1h; or fastcgi_cache_valid 301 1h;), that takes precedence for redirects. Thus:

200 -> 60s
301 -> 1h (stale redirect loop window)

[mathiasoem]

@blydewright Yes it is enabled - and the issue is gone when deleting /var/cache/nginx and reloading nginx. But that doesn't necessarily mean that the cache is the actual cause of the issue.
It might just make it visible to us for an hour at a time instead of just a single request. Hard to tell I guess.

I do experience the issue several times a day on some sites.

[retlehs]

After upgrading a bunch of sites from 1.22 to 1.25 (pretty sure it also happens on 1.24)

Based on the diff, this is the only relevant change: #1513

[swalkinshaw]

Commenting out the add_header X-Cache-Enabled line would be a quick way to test this if anyone is able to

[blydewright]

Some feedback from my end - my theory above did not work. Still the same issue.

Also, this particular project is on Trellis 1.23 which does not include the add_header X-Cache-Enabled line.

If my issue is indeed the same as @mathiasoem, it may relate to >= 1.23.

[mathiasoem]

This is just a guess. But could it have something to do with the https firewall rule added here? #1530

If wordpress is somehow blocked on the https request it might register the site at not being on https, and therefore redirects to the https url.

[artshostak]

Having this exact issue and getting periodic:
ERR_TOO_MANY_REDIRECTS

Will see if disabling cache helps but subscribing to see how it's resolved!

Edit: disabling caching resolves the issue. But what is the solution here as I'd like to keep caching enabled across other projects. Let me know if anyone has any thoughts and workarounds here!