A custom login path can work at the origin while the CDN redirects visitors or serves a cached 404. Login responses depend on cookies, nonces, private state, and fresh redirects that do not belong in a shared page cache.
Compare the same request at the edge and origin, then give every authentication transition a precise cache bypass before purging stale entries.
What it means
A cache or CDN conflict occurs when an intermediary stores, rewrites, redirects, challenges, or routes an authentication path differently from WordPress. A response that is correct for one anonymous request may be wrong or unsafe for another user.
Custom login, administration, logout, password recovery, and related callback routes should remain private and dynamic.
A realistic WordPress example
The custom route works at the origin, but a cache-everything rule stores an anonymous 404 and ignores WordPress no-cache signals. Some visitors receive that 404, while another edge rule redirects others to the home page.
Exact bypass rules for the login and recovery paths, followed by a scoped purge, restore consistent behavior without disabling public caching.
Why it matters and when to use it
A shared login response can block access, leak state, or serve a redirect or cookie behavior created for one user to another. Broad cache disabling, however, can needlessly reduce performance across the site.
Use this diagnosis when login behavior differs by location, session, locale, cache status, or direct-origin access.
A straightforward route for beginners
- Capture one public and one authorized origin response for the same path.
- Compare status, Location, Cache-Control, Set-Cookie, Age, and cache-status headers.
- List custom login, wp-admin, logout, lost-password, reset, and registration routes.
- Create exact dynamic bypass rules for those routes.
- Purge only the affected cached paths.
- Test cold and warm requests from logged-out and logged-in sessions.
The advanced route
Review cache-key host, query, cookie, method, locale, and device variants. Confirm that edge redirects preserve reset parameters and that security challenges do not intercept recovery unexpectedly.
Test anonymous login, administrator access, logout, password reset, callback, and localized variants across several edge locations. Authenticated and key-bearing responses must not enter shared storage.
Risks, common mistakes, backup, and rollback
A wildcard bypass can remove useful caching from much of the site, while an incomplete bypass leaves a related recovery route exposed. Purging first destroys evidence without fixing the rule that will recreate the entry.
Export edge rules and keep direct recovery access. Roll back the new cache policy if private state cannot be isolated, then restore the last accepted bypass while refining the match.
How AIOWS helps:
AIOWS Login Manager
AIOWS Login Manager can define the supported custom WordPress login route that the cache and CDN must exempt from public caching. Its route configuration defines the WordPress paths that the CDN must treat dynamically.
Keep a known-good session, confirm every related authentication transition, and test the origin before changing edge behavior. After the bypass is in place, retest the custom route and recovery from clean browsers.
Login Manager cannot enforce every external CDN cache rule or purge every provider. Edge configuration must respect the dynamic WordPress routes and preserve private response headers.
Related AIOWS articles
- Change WordPress Login URL Safely: Complete Guide
- Custom WordPress Login URL Returns 404
- How to Configure Browser Caching for WordPress
Conclusion and recommended route
Compare the origin and public edge, give every authentication transition an exact dynamic bypass, and then purge stale responses. Public content can remain cached; login, recovery, cookies, and redirects must stay private and fresh.
