{"version":"2.1.224","anchor":"blocked-by-proxy-responses-are-detected-from-a-second-header","canonical_anchor":"blocked-by-proxy-responses-are-detected-from-a-second-header","heading":"Blocked-by-proxy responses are detected from a second header","tier":"notice","area":"Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224\/e\/blocked-by-proxy-responses-are-detected-from-a-second-header","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224","markdown":"### Blocked-by-proxy responses are detected from a second header\n\nProxy-blocked requests are recognised from a second header, so more networks get the proper message.\n\n**What**\n\nWhen a request is refused by a network proxy allowlist, Claude Code now recognises the block from either of two response headers, so more environments get the proper \"blocked by egress policy\" handling instead of a generic HTTP 403.\n\n**Details**\n\n- An HTTP 403 counts as blocked when `x-proxy-error` is `blocked-by-allowlist` or when the new `x-deny-reason` header is `host_not_allowed`.\n- Previously only the first header was checked, and only at the GitHub comments call site; the check is now a shared helper.\n\n**Evidence**\n\n`host_not_allowed`\n\n- Area: Internals\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}