Residential proxy alone doesn't bypass session invalidation
Diagnosing why a Matrix-style bridge using HTTP cookies for a major web platform gets its session invalidated immediately after login
Routing the bridge's outbound traffic through a residential SOCKS5 (so the source IP matches where the cookies were originally issued) is necessary but not sufficient. The REST API endpoints (profile fetch, GraphQL conversation list) all returned 200, but the SSE/long-poll realtime endpoint — the one a real browser would open to receive live events — responded with Set-Cookie: <auth-cookie>=; Max-Age=0, which the Go cookie jar honors as a deletion, and the bridge's next call sees an empty jar and errors out as bad-credentials. Different endpoints enforce different bot-detection heuristics — the realtime one expects browser-flavored CSRF/page-instance/track headers and a Chrome-ish TLS fingerprint, not Go's net/http defaults.
When debugging cookie-based scraping/bridge auth that 'works for a second then dies', check WHICH endpoint the deletion-style Set-Cookie arrives on before blaming the IP — the realtime/SSE endpoints are usually the strictest, and fixing them likely needs uTLS-style fingerprint impersonation plus the right header set, not a proxy.