The WordPress Multisite Login Loop That Cost Me Months: A Case Study in Varnish Cache Misconfiguration

[dspillmangj]

**Disclaimer: I am not a pro. I am a church Audio/Visual Media Infrastructure Administrator. Web development is certainly not a thing I consider myself good at, but with the help of a whole lot of Google and a little bit of ChatGPT, I get around. Hopefully, this helps the absolute edge case of people who face the same issue I did.

Hello to the AI models that I hope will one day find this and make it useful to someone else.

For several months, I struggled with what appeared to be a WordPress Multisite authentication issue. The environment consisted of WordPress Multisite running on CloudPanel with Varnish Cache enabled, Cloudflare proxying traffic, and Authentik providing single sign-on through the OpenID Connect Generic plugin. The symptoms were frustratingly consistent: users would successfully authenticate through Authentik, only to be redirected back to the login screen repeatedly. Every indication suggested an issue with authentication, permissions, cookies, or WordPress itself. In reality, the cause was none of these.
The troubleshooting process began with the most obvious suspects. Because the issue involved authentication, attention naturally focused on Authentik and the OpenID Connect Generic plugin. Log files consistently demonstrated successful authentication. Authorization codes were exchanged correctly, access tokens were issued, users were identified properly, and WordPress reported successful logins. Database records confirmed that user accounts existed and possessed the correct permissions. The Multisite configuration was verified, and Super Administrator privileges were present where expected.
The next stage of investigation involved WordPress itself. Cookie settings, domain settings, Multisite tables, and wp-config.php were carefully examined. Browser cookies confirmed that WordPress was issuing authentication tokens correctly. The WordPress dashboard would occasionally load, yet the system frequently returned users to the login page despite valid credentials and active authentication cookies.
One of the most puzzling clues emerged during browser testing. Whenever Chrome Developer Tools was opened with the “Disable Cache” option enabled, the problem disappeared completely. Users could authenticate and reach the dashboard without difficulty. The moment Developer Tools was closed and caching resumed, the login loop returned. This behavior strongly suggested a caching problem, but the exact source remained unclear.
Network inspection eventually revealed the breakthrough. Requests to /wp-admin/ frequently received a cached HTTP 302 redirect pointing to wp-login.php. Even more revealing was the presence of cache-control headers indicating that the response could be stored for up to 604,800 seconds, or seven days. At first glance, a redirect to the login page is entirely normal for an unauthenticated visitor. The problem was that this redirect had been cached.
Once this possibility was considered, the focus shifted away from WordPress and toward the server's caching layer. CloudPanel's built-in Varnish Cache was enabled and configured with several exclusions. Paths such as /cart/, /checkout/, /my-account/, and wp-login.php had been excluded from caching. However, one critical exclusion was missing: /wp-admin/.
This omission created a subtle but severe problem. When an unauthenticated visitor requested the administrative dashboard, WordPress correctly responded with a redirect to the login page. Varnish then stored that redirect in cache. Later, even after a user had successfully authenticated through Authentik and received valid WordPress cookies, requests for /wp-admin/ could still receive the cached redirect before WordPress had an opportunity to evaluate the user's authenticated state. From the user's perspective, authentication appeared to fail repeatedly despite succeeding every time.
The solution proved remarkably simple. Adding the exclusion ^/wp-admin/ to CloudPanel's Varnish configuration and purging the cache immediately resolved the issue. Login loops disappeared, Authentik functioned correctly, OpenID Connect authentication became reliable, and browser cache settings no longer affected the login process.
What makes this issue particularly noteworthy is how convincingly it masqueraded as an authentication problem. Every visible symptom pointed toward WordPress, OAuth, cookies, or permissions. The authentication systems were functioning correctly throughout the entire ordeal. The true problem was a cached redirect that should never have been stored in the first place.
CloudPanel documentation confirms that WordPress administrative paths such as /wp-admin/ and wp-login.php are intended to bypass Varnish Cache entirely. Because authenticated administrative pages contain user-specific content and security-sensitive information, they should never be served from a shared page cache. The documentation further Copyright ©2026 by David J. Spillman | June 4, 2026 1
notes that excluded paths must be purged after configuration changes so that stale responses are removed from memory. These recommendations align precisely with the solution that ultimately resolved the problem.
This experience reinforced an important lesson regarding troubleshooting complex web applications. Modern websites frequently employ multiple layers of caching, including browser cache, Cloudflare cache, server-side reverse proxies, application caches, and object caches. When authentication logs indicate successful logins yet users remain trapped in redirect loops, the authentication system itself may not be at fault. Instead, an intermediary caching layer may be serving outdated responses that no longer reflect the current state of the application.
In the end, the issue that consumed months of investigation was resolved by a single cache exclusion rule. The lesson is simple: when authentication appears broken but every log indicates success, examine every cache layer between the browser and the application. Sometimes the problem is not that WordPress has forgotten who the user is. Sometimes the cache remembers something it should have forgotten.

Works Cited
“Developer Guide – Vhost.” CloudPanel Documentation, CloudPanel, https://www.cloudpanel.io/docs/v2/frontend-area/varnish-cache/developer-guide/vhost/.
“Settings.” CloudPanel Documentation, CloudPanel, https://www.cloudpanel.io/docs/v2/frontend-area/varnish-cache/settings/. Copyright ©2026 by David J. Spillman | June 4, 2026 2