Ok think i am making progress. I believe the stale token was a phantom issue or maybe was an issue with previous xo build, and AI just hung onto that idea. To the best of my knowledge the tokens seem to be working correctly. That is they update when i refresh or log out and log in. If i delete the token and log back it generates a new token. If i log in form a different computer it generates a new token for that login. I need to wait for the token to past its expire date/time.
I think to real is actual problem is with the v6 dashboard issue. Last thing need to test is build another and export this config and import into new and see if it blows up.
That's the first read. The two last_uses timestamps are:
10.100.10.131 → 1779489071582 (2026-05-22 22:31:11 UTC)
127.0.0.1 → 1779489074416 (2026-05-22 22:31:14 UTC)
Both correspond to your fresh login activity and the tcpdump capture window. Now wait ~60 seconds and run it again:
sudo redis-cli get xo:token:Olbs11w5o
If the 10.100.10.131 timestamp advances to a more recent value, the v6 UI is sending the token cookie successfully on some requests — meaning the 401s on /dashboard are from a specific code path in the v6 UI that omits the cookie (upstream bug).
If the timestamp does not advance, the v6 UI stopped sending the cookie entirely after the initial page load — which would be a cookie-scope or SameSite issue we can potentially fix on the server side.
❯ sudo redis-cli get xo:token:Olbs11w5o
"{"client":"{}","created_at":1779488912916,"description":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","user_id":"7e6d04ac-415e-4355-8dd6-3465467c7df1","expiration":1779524912916,"last_uses":{"10.100.10.131":{"timestamp":1779489071582},"127.0.0.1":{"timestamp":1779489074416}},"client_id":"itsdbb2c0ni"}"
I ran it again after refreshing the browser a few times...
❯ sudo redis-cli get xo:token:Olbs11w5o
"{"client":"{}","created_at":1779488912916,"description":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","user_id":"7e6d04ac-415e-4355-8dd6-3465467c7df1","expiration":1779524912916,"last_uses":{"10.100.10.131":{"timestamp":1779489677313},"127.0.0.1":{"timestamp":1779489674082}},"client_id":"itsdbb2c0ni"}"
The timestamps did advance:
10.100.10.131: 1779489071582 → 1779489677313 (+10 min)
127.0.0.1: 1779489074416 → 1779489674082 (+10 min)
So after refreshing the browser, your valid session token is being used and last_uses updates correctly. That means the v6 UI does send the cookie on most requests — auth works for normal page loads and most API calls.
But the /dashboard (401) polling continues independently of those successful authenticated requests. That's the smoking gun: the v6 UI's dashboard widget polls /dashboard without attaching the auth cookie, even when the rest of the app is properly authenticated.
This is definitively an upstream XO 6 UI bug, not a problem with:
This install script
Your xo-config.cfg settings
The NPM reverse proxy
Your browser session
Conclusions for your situation:
The 401 noise is cosmetic — your XO works fine, the dashboard widget just polls a route it shouldn't (or doesn't authenticate the poll).
Nothing in this project needs to change. The install script, config rendering, and Redis cleanup logic are all working as designed.
The right next step is to report it to Vates at https://github.com/vatesfr/xen-orchestra: "XO 5.201.0 web (v6) polls /rest/v0/dashboard every 31s without auth cookie even when user is logged in, producing log spam and Redis warnings."
