Unexpected XenForo logouts can result from cookies set for a different hostname, HTTPS termination differences, session storage faults or browser privacy restrictions. Users often report being signed out while switching between www and non-www URLs or returning from an external login flow. A broad cache purge may hide the symptom briefly but cannot fix a persistent hostname or proxy mismatch.
Symptoms: identify the exact failure
Before changing a setting, reproduce the issue once and write down the affected product, operating-system or service version, error text, time, and what still works. One useful observation narrows the fault domain far more than several indiscriminate resets.
- Signal 1: Login works on apex domain but fails at www hostname
- Signal 2: Members log out after redirecting between HTTP and HTTPS
- Signal 3: Most browsers work but a privacy-restricted profile repeatedly loses session
Why this happens
Different failure points can produce nearly identical messages. A fix is more reliable when it targets the failing layer rather than the nearest visible symptom.
- Cookie scope or SameSite/Secure attributes differ from actual public origin
- Reverse proxy does not forward host or HTTPS scheme consistently
- Session storage, security policy or browser settings invalidate saved state
Before making changes
Protect data and preserve a rollback path. Never paste session cookie values, authorization headers or user credentials into support tickets. Record configuration before editing reverse-proxy trust. Use a non-admin test account for login experiments and keep HTTPS enforcement enabled.
Recommended approach: Perform the low-risk checks first. Record the original value of every setting you change, test the exact failing action after each step, and stop when the result is repeatable. Avoid applying several unrelated remedies at once.
Step-by-Step Troubleshooting
The steps below are stored in PRBLEM’s editable Beginner and Advanced troubleshooting fields. Select a method appropriate to your experience; the Beginner sequence focuses on reversible checks, while Advanced actions are intended for administrators or users comfortable collecting diagnostic evidence.
Step-by-Step Troubleshooting
Follow the reversible checks in order; use Advanced only if authorized and preserve the original settings.
Reproduce with one test account
Use a standard account and note exact successful login URL, redirect chain and time until logout; avoid changing security settings first.
Verify canonical board hostname and scheme
Check XenForo board URL and intended https:// hostname. Redirect both www and non-www consistently instead of mixing cookie origins.
Inspect cookie attributes safely
In browser developer tools, check cookie domain, path, Secure, HttpOnly and SameSite labels, but do not copy cookie values.
Review proxy and CDN forwarding
Confirm trusted reverse proxy sends correct original host and HTTPS scheme. An application that believes requests are HTTP may generate incorrect redirects or cookies.
Check browser isolation factors
Compare private browsing, extensions and strict tracking controls for the test account; preserve ordinary browser security features.
Review session errors and caching
Inspect XenForo logs, session database/cache health and recent add-on changes. Avoid caching personalized pages or Set-Cookie responses at the CDN.
Change one verified mismatch
Apply the documented board URL/proxy or cache correction, invalidate only necessary affected sessions, then verify repeated logins and navigation.
Trace redirects and Set-Cookie headers in a safe environment
Capture status codes and cookie attribute names with values redacted; identify where host/scheme divergence begins.
Audit proxy trust boundaries
Restrict forwarding-header trust to known proxies so untrusted clients cannot spoof HTTPS or host state.
Check multi-node session consistency
Verify application secrets, caches and shared session backends are consistent across nodes after deployments or scaling events.
Interpret the results
Do not treat one successful retry as proof of a permanent fix. Compare the outcome with the following decision guide and note exactly which check changed the result.
| What you observe | Likely direction | Next safe action |
|---|---|---|
| Login works on apex domain but fails at www hostname | Cookie scope or SameSite/Secure attributes differ from actual public origin | Reproduce with one test account: Use a standard account and note exact successful login URL, redirect chain and time until logout; avoid changing security settings first. |
| Members log out after redirecting between HTTP and HTTPS | Reverse proxy does not forward host or HTTPS scheme consistently | Inspect cookie attributes safely: In browser developer tools, check cookie domain, path, Secure, HttpOnly and SameSite labels, but do not copy cookie values. |
| Most browsers work but a privacy-restricted profile repeatedly loses session | Session storage, security policy or browser settings invalidate saved state | Check browser isolation factors: Compare private browsing, extensions and strict tracking controls for the test account; preserve ordinary browser security features. |
How to verify the fix
Pass condition: A test account stays logged in across intended site navigation and a new browser session, while secure HTTPS cookies and forum permissions remain enforced.
Repeat the original operation at least twice, including after a normal restart or reconnect where appropriate. Confirm that unrelated features still work and that security, backups and access controls remain enabled. Record the tested version and time so future incidents can be compared accurately.
Common mistakes to avoid
- Avoid: Turning off Secure or HttpOnly cookie protections to hide session failure
- Avoid: Publishing live session tokens when sharing diagnostics
- Avoid: Disabling CDN caching globally instead of isolating personalized routes
If the issue persists
If multiple users still lose sessions, provide sanitized request traces, board URL/proxy settings, PHP/XenForo versions and time correlation to the hosting and XenForo support teams.
Include with a support request: the reproducible steps, exact error or status, affected and known-good versions, what changed, and the checks already completed. Remove passwords, tokens, payment data, private messages and personal identifiers from screenshots and logs before sharing.
Solution Checklist
Official reference
For product-specific menus and current behavior, consult XenForo support community. Features and menu labels can vary by version; verify them against your environment before making lasting changes.