{"version":"2.1.242","anchor":"failed-websocket-upgrades-are-reported-with-the-reason-not-j","canonical_anchor":"failed-websocket-upgrades-are-reported-with-the-reason-not-j","heading":"Failed WebSocket upgrades are reported with the reason, not just a status","tier":"internal","area":"Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/failed-websocket-upgrades-are-reported-with-the-reason-not-j","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### Failed WebSocket upgrades are reported with the reason, not just a status\n\nFailed WebSocket connections now record why, separating a server rejection from a Cloudflare block.\n\n**What**\n\nWhen a WebSocket connection fails to upgrade, the recorded outcome now distinguishes a rejection by the server from one mitigated by Cloudflare, with the HTTP status appended and clamped to 100 to 599. Close reasons for asks that were shown locally but never forwarded are flagged separately.\n\n**Evidence**\n\n`cf_mitigated`\n\n- Area: Internals\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}