在前端开发、接口调试甚至逆向爬虫的场景里修改请求头是常规操作。但很多人不知道浏览器对请求头有严格的安全管控不是所有字段都能随意修改 —— 有些字段写了会直接报错有些写了请求直接失效甚至会触发安全风险。本文基于Fetch 标准规范与浏览器同源策略完整梳理浏览器环境下不能乱写的请求头字段以及背后的原因与后果。一、硬性禁止写了也无效还会报错的字段这类字段被称为禁止修改的请求头Forbidden Request Header由 W3C Fetch 规范明确定义所有主流浏览器Chrome/Firefox/Safari/Edge统一遵循。无论同源还是跨域只要通过 JavaScriptFetch、XHR、Axios 等封装库手动设置这些字段浏览器都会直接忽略配置甚至抛出Refused to set unsafe header错误。它们的控制权完全属于浏览器本身不向脚本开放。1. 核心路由与安全类字段Host指定请求的目标主机名和端口是 HTTP/1.1 协议的必填字段。浏览器会自动根据请求 URL 生成该字段禁止手动修改 —— 一旦允许伪造就会引发主机头攻击、域名劫持等安全风险。Origin标记请求的来源站点协议 域名 端口是 CORS 跨域校验的核心依据。浏览器自动生成并注入完全不允许脚本覆盖否则同源策略的安全屏障会直接失效。Referer记录当前请求的来源页面地址用于防盗链、统计分析和 CSRF 防护。浏览器根据页面上下文自动携带仅能通过Referrer-Policy控制发送规则无法手动伪造具体值。Cookie / Cookie2携带浏览器存储的站点 Cookie受同源策略和 HttpOnly 等属性严格保护。脚本完全不能手动设置请求头中的 Cookie 字段只能通过document.cookie操作同域非 HttpOnly 的 Cookie最终由浏览器自动拼接到请求中。2. 连接与传输控制类字段Connection / Keep-Alive控制 HTTP 连接的复用与关闭连接生命周期完全由浏览器统一管理包括 TCP 复用、HTTP/2 多路复用。脚本无法干预手动设置会被直接忽略。Content-Length标记请求体的字节长度由浏览器根据请求体内容自动计算。禁止手动修改是为了防止请求走私攻击避免因长度不匹配引发的协议解析异常。Transfer-Encoding / Trailer / TE / Expect / Upgrade均属于 HTTP 传输层控制字段分块传输、协议升级等行为均由浏览器底层处理脚本无权修改。3. 两类前缀禁用的字段只要字段名匹配以下前缀全部属于禁止修改范围Proxy-开头的所有字段用于代理服务器通信客户端无权设置。Sec-开头的所有字段浏览器专属的安全头比如常见的Sec-Fetch-Site、Sec-Fetch-Mode、Sec-CH-UA等全部由浏览器自动注入用于服务端做安全校验禁止脚本伪造。4. 其他禁止字段还有Date、DNT、Permissions-Policy、Via、Access-Control-Request-Headers、Access-Control-Request-Method等字段均属于浏览器管控范围不开放脚本修改权限。二、非强制禁止但绝对不能乱写的字段这类字段不在官方禁用列表中部分场景如浏览器插件、抓包工具、爬虫客户端可以修改但在正常浏览器网页环境中随意填写会直接导致请求异常、业务失效。1. User-Agent虽然脚本层面有限度可修改但强烈不建议乱写服务端会根据 UA 做页面适配、兼容性处理乱填可能导致返回错乱的页面内容现代浏览器正在逐步冻结 UA 字符串推广 UA Client Hints 体系伪造 UA 极易被反爬系统识别拦截部分浏览器已开始限制脚本对 UA 的修改权限未来会逐步纳入严格管控。2. Content-Type标记请求体的媒体类型是服务端解析参数的核心依据乱写直接导致接口拿不到数据提交 JSON 数据却写成text/plain后端会无法解析请求体文件上传场景的multipart/form-data绝对不能手动设置 —— 浏览器会自动生成 boundary 分隔符手动填写会破坏格式导致文件上传完全失效。3. Accept-Encoding声明客户端支持的压缩算法gzip、br 等。如果乱写浏览器不支持的压缩格式服务端返回压缩后的数据浏览器无法解压最终页面或接口返回乱码。4. Authorization用于携带鉴权凭证如 Token本身允许脚本设置但不能乱写格式错误或值无效会直接导致鉴权失败返回 401 错误跨域场景下携带该字段会触发 CORS 预检请求需要服务端单独放行明文存储或误写入公共场景会引发凭证泄露风险。5. X-Forwarded-For / X-Real-IP这类是代理层用于传递客户端真实 IP 的字段客户端手动填写完全无效 —— 正规服务端只会信任代理层添加的 IP客户端伪造的数值不仅不会被采纳还可能被反爬系统标记为异常请求。三、乱写请求头的常见后果浏览器直接拦截报错触碰禁止修改的字段时控制台会抛出Refused to set unsafe header错误请求可能直接终止。跨域请求失败伪造 Origin、自定义未放行的头字段会导致 CORS 预检不通过浏览器直接拦截响应前端拿不到数据。服务端处理异常Host、Content-Type、Content-Length 等字段异常会导致服务端返回 400 Bad Request、403 Forbidden甚至完全无法解析请求。触发反爬与风控拦截异常的 UA、Referer、Sec-* 头缺失或伪造是反爬系统最基础的识别特征轻则请求被拦截重则 IP 被封禁。安全风险与协议漏洞随意修改传输类、路由类头字段可能引发请求走私、HTTP 响应拆分等协议级安全漏洞。四、哪些请求头可以放心修改浏览器开放修改权限的主要是业务协商类、内容协商类字段以及自定义业务头内容协商类Accept、Accept-Language、Cache-Control业务鉴权类Authorization按需合法使用自定义头以X-开头的业务自定义字段比如X-Request-Id、X-Token等正确修改的注意事项跨域场景下自定义请求头会触发 OPTIONS 预检请求需要服务端在Access-Control-Allow-Headers中放行对应字段。不要在请求头中携带明文敏感信息鉴权凭证遵循服务端规范的格式。优先通过请求库的拦截器统一配置避免逐个请求手动添加减少格式错误。总结浏览器请求头的修改边界本质上是安全与可控性的平衡凡是涉及连接管理、路由寻址、安全校验的字段全部由浏览器接管禁止脚本干预仅业务协商类、自定义字段开放给开发者配置。调试接口时遇到设置不生效的情况优先排查是否触碰了禁止修改的字段而非反复尝试绕过 —— 遵循 HTTP 规范与浏览器安全策略才是最稳妥的方案。
