直接说结论Location头按现行 HTTP 规范允许写相对引用浏览器也会帮你补全成绝对路径但服务端生成响应时最稳妥的做法仍然是输出完整的绝对 URI。这个问题在项目里不遇到还好一遇到就是跳转错乱、登录死循环、爬虫抓取异常这类让人头疼的线上故障。1. 先从一个踩坑现场说起Location 头到底在项目里做什么1.1 重定向不只是 302 状态码那一行Location头是 HTTP 响应头里一个不起眼但极其关键的字段。只要响应状态码是3xx301、302、303、307、308Location就是服务器告诉客户端“你要去的地方”。201 Created响应里它也能出场用来标识新创建资源的地址。很多新手以为重定向就是把状态码改成 302 就完事了实际上浏览器拿到 302 之后会立刻去找Location头找不到就停在原页面或者干脆白屏。这个头的语义是“下一跳地址”服务器说你去哪就必须把这个地址写清楚否则客户端只能靠猜。还有一点容易被忽略Location只负责“目标地址”不负责“这次用什么方法跳”。比如 302 通常把 POST 变 GET307 会保留原请求方法和 Body308 则是永久重定向且保留方法。这些状态码组合Location的行为差异是后端排查跳转问题时最容易绕进去的一个弯。1.2 一次“本地正常、上线跳错”的典型事故某项目的管理后台遇到了一个经典故障用户会话过期后点击任意页面都被拦截跳到登录页但生产环境里这个跳转老是出问题要么跳到子路径下的错误位置要么登录成功后回跳又死循环。本地开发环境一切正常部署到二级目录后就全乱了。抓包后发现响应头里赫然写着HTTP/1.1 302 Found Location: login这个login是相对路径。本地服务跑在根路径/浏览器把它解析成http://localhost:8080/login恰好正常。生产环境整个应用部署在/business/app/下浏览器基于当前页面 URL 解析后得到的是http://example.com/business/login而不是预期的/business/app/login登录页直接 404。这个故障就是典型的“本地环境掩盖了相对路径问题”。浏览器很宽容会自动补全相对路径但补全依据是“当前页面地址”不是“你心里想的那个根目录”。一旦部署路径变了跳转就跟着错而且这种错很难直观看出来因为响应头里那一行太不起眼了。2. 标准到底怎么写从强制绝对 URI 到允许相对引用2.1 老规范强制绝对 URI这个知识点值得先搞清楚HTTP 协议规范经历过一个重要的口径变化。早期的 HTTP/1.1 规范里明确写过Location字段值必须是“单个绝对 URI”。也就是说理论上服务器只输出https://example.com/new/path这种完整地址才算符合规范。那个年代这么规定是有道理的。早期的 HTTP 客户端交互没有现在这么智能很多下载工具、爬虫、脚本拿到Location后直接就用了如果给一个相对路径客户端还得知道“基于哪个 URL 去做解析”一旦请求经过多层代理这个基准 URL 很容易变味最后跳到一个谁都想不到的地方。所以老规范选择了最简单粗暴的方式服务器必须把地址写全。你负责把绝对地址算出来客户端只管跟着走。2.2 现行规范允许相对引用了但推荐度仍然不高到了后面的新版规范情况有了变化。Location被定义为单个URI-reference也就是允许相对引用的存在。规范同时说明当字段值是相对引用时接收方应该基于“有效请求 URI”去解析目标地址。换句话说按现行标准Location: login、Location: /path、Location: ../home都不能算错误。浏览器也会按规则把它们补全成绝对 URL。这个改动是为了照顾一些不方便生成完整绝对地址的动态页面场景也让规范本身更符合 URI 的通用模型。但规范放开了不代表实践上就要浪。RFC 7231 里同时有一句很重要的建议除非请求目标本身就是相对引用否则发送方不应该生成相对引用。原因很简单虽然规范允许但不同客户端在“基准 URL”的判定上存在差异尤其是非浏览器客户端、老旧程序、硬件设备它们对相对引用的解析能力参差不齐。所以在项目里我始终建议把Location当成“绝对路径优先”的字段来对待。规范允许是一回事线上稳定是另一回事。2.3 三种“相对”形态各有各的脾气Location值的形态大体分四种看起来差异不大解析结果完全不同。假设当前页面地址是https://dev.example.com/business/app/page?id1Location 的写法浏览器最终跳转到的地址说明https://new.example.com/homehttps://new.example.com/home完整绝对 URI最推荐//new.example.com/homehttps://new.example.com/home协议相对 URL跟随当前页面的协议/homehttps://dev.example.com/home根相对路径直接替换整个路径home或../homehttps://dev.example.com/business/app/home或https://dev.example.com/business/home相对当前目录最容易被误解的一类?tab1https://dev.example.com/business/app/page?tab1只替换查询参数这里面最坑的就是不带斜杠的写法比如login和/login。差一个斜杠解析出来的地址相差十万八千里。前者是“当前目录下的 login”后者是“站点的根目录下的 login”。//开头这种协议相对地址也经常被误解。它会把协议换成当前请求的协议但保留域名。如果当前是 HTTP 页面那Location //example.com/xxx就会继续走 HTTP在 HTTPS 改造过程中容易造成“跳了又跳、始终没进 HTTPS”的死循环。3. 浏览器、服务端框架、反代层各自怎么处理3.1 浏览器地址栏里的真实表现浏览器解析Location头用的是 URL 标准里的“解析相对引用”逻辑基准是发起请求的那个 URL。用户看到的地址栏永远是解析后的绝对地址不会显示成Location里写的那个原始字符串。这带来一个体验上的假象看起来浏览器什么都能处理写相对路径也没问题。实际上浏览器确实是兼容性最好的那一拨curl、requests这类 HTTP 工具也基本能做正确解析。但一些嵌入式客户端、老版本的下载工具、设备固件里的 HTTP 栈就没那么完善了它们可能直接把Location: login原样当成一个完整地址去请求得到一个无法解析的乱地址。还有个小细节页面里的base标签不会影响Location的解析基准。有些同学以为改了base href...就能让相对重定向跳到指定位置这是不对的Location用的是请求 URL不是文档 URL。3.2 服务端框架生成 Location 的常见逻辑服务端生成Location的方式五花八门。有些框架会主动把相对地址补全成绝对地址补全依据是请求里的Host头有些框架则支持直接把传进来的字符串当成Location值原样返回不做任何处理还有一类框架在生成登录跳转、OAuth 跳转时会要求你显式传入完整的回调地址。这里有一个陷阱依赖请求里的Host头来拼绝对地址在正常情况下没问题但一旦服务前面挂了反代客户端访问的是https://example.com到了后端服务器手里的请求Host头却可能变成http://192.168.1.10:8080这种内网地址。如果后端基于这个Host拼Location生成出来的绝对地址会变成http://192.168.1.10:8080/login。浏览器拿到后要么跳到一个内网 IP 地址要么因为 HTTPS 页面往 HTTP 地址跳而被强制拦截。这种故障和相对路径问题一样隐蔽排查时容易把锅甩到“HTTPS 证书”或“代理配置”上。3.3 反代和网关层改写 Location 时的经典陷阱反向代理、API 网关这类中间层经常会改写响应头。它们内部有一种常见的机制专门修正从上游返回的Location头因为上游服务可能不知道自己的对外地址是什么直接返回的是内网地址或相对路径。如果代理配置不当可能出现双重改写上游返回了一个相对路径代理在转发的时候想当然地给它拼上了内部域名浏览器拿到手就变成了一个无法从公网访问的地址。还有一种场景是代理把上游的Set-Cookie、Location等头都做了绝对化处理但拼接时把协议写死成了 HTTP导致 HTTPS 站点下的跳转全被浏览器拦掉。多级代理场景更难受A 代理把相对路径补成http://internal-a/xxxB 代理又把这个地址当成上游地址转发最后客户端收到一个嵌套了内网域名的畸形Location。排查这类问题时不能只看浏览器最终地址一定要逐层抓包看原始响应头。4. 相对路径带来的三个安全大坑4.1 开放重定向与钓鱼话术Location的值如果来自用户可控的参数比如redirect_uri、next、returnUrl而服务端没有做合法性校验就会形成开放重定向漏洞。攻击者可以构造一个官方链接点击后却被Location带到钓鱼站。相对路径在这个问题上有一种迷惑性开发者觉得“我只允许站内相对路径跳转安全性没问题”。实际上攻击者照样可以利用协议相对地址//evil.com或者把相对路径构造得像站内路径却通过解析歧义诱导到其他域名。只要生成逻辑里没有对最终解析结果做强校验就可能出问题。防御上我养成了一个习惯所有跳转地址必须过白名单校验。站内跳转就从路径参数里取固定前缀外站跳转必须匹配允许的域名列表否则一律跳到默认页。4.2 响应头注入与 CRLF 风险Location是响应头值是字符串。如果这个字符串可以由用户输入拼接出来又没有过滤回车换行符攻击者就能往响应头里注入额外字段。最经典的利用方式是注入Set-Cookie篡改会话或者注入其他响应头做信息劫持。有人可能会说“我做的是相对路径跳转只拼了路径部分不会有换行符”。实操里这种信心很危险用户输入经过多次解码、编码转换后完全可能夹带%0d%0a这类 CRLF 序列。后端在处理Location生成时必须对用户可控部分做严格校验和编码宁可拒绝跳转也不能原样拼接。4.3 缓存、抓取与 Referer 的信息歧义Location用相对路径还有一个容易被忽视的副作用当同一份响应被 CDN 或浏览器缓存后不同入口解析出的目标地址可能不一样。Location: /home在根域名下访问没问题从子目录访问时就跳到了子目录的上一级语义全变了。此外重定向到外部站点时浏览器默认会携带Referer头。如果原地址里有token、sessionId这类敏感参数就会泄露给外部站。跳转用的相对路径本身不会泄露完整参数但一旦中间层把Location解析拼成带参数的绝对地址泄露面就大了。安全的做法是外跳前脱敏或者用服务端中转页承接。5. 项目里处理 Location 的实操守则5.1 统一生成绝对 URL 的三个经验第一个经验不要在代码里到处写死跳转地址更不要随手拼字符串。定义一个统一的站点基础地址配置项包含协议、域名、部署根路径所有重定向生成都用它做前缀。这样即使部署到二级目录只需要改一处配置所有跳转都跟着变。第二个经验生成绝对地址时协议和域名要从配置读不要从Host头读。Host头是可以被伪造的而且经过反代后大概率不是客户端看到的那个地址。用配置管理对外地址才能保证 HTTPS 站点不会跳出 HTTP 域名来。第三个经验所有来自用户输入或外部传入的跳转目标必须经过白名单校验。可以写成类似这样的伪代码逻辑func buildRedirect(relativePath string) string { // 只允许站内路径作为跳转目标 if !strings.HasPrefix(relativePath, /) !strings.HasPrefix(relativePath, /business/) { return siteBaseURL /error/invalid-redirect } // 禁止任何形式的协议相对或绝对地址绕过 if strings.Contains(relativePath, ://) || strings.HasPrefix(relativePath, //) { return siteBaseURL /error/invalid-redirect } return siteBaseURL normalizePath(relativePath) }这套逻辑看起来粗暴但在线上非常有用要么跳站内路径要么跳默认错误页不给攻击者留解读空间。5.2 用 curl 和浏览器抓包验证的全过程排查Location问题时我一般先用 curl 做第一轮检查。curl -sI只打印响应头不跟随跳转非常适合看原始输出curl -sI https://example.com/old/path | grep -i location能看到Location的原始值到底是相对还是绝对。如果想跟随重定向看最终落点用curl -sL -o /dev/null -w %{url_effective}\n https://example.com/old/path它会显示最终生效的地址同时也能观察有没有跳转循环。浏览器这边则用开发者工具的 Network 面板点击那条 302 记录在 Response Headers 里展开看Location的原始值。注意浏览器开发者工具里显示的地址通常是解析后的结果要区分清楚。如果怀疑是代理改写还需要在具备抓包条件的环境里看原始响应光看浏览器端不一定能发现问题。5.3 高频问题排查速查表故障现象可能原因检查点登录后回跳陷入死循环Location指向自身或相对路径被解析成环抓包看每一次 302 的Location是否在预期范围内部署到子目录后跳转全乱代码里写的是不带斜杠的相对路径检查Location是login还是/login以及与BASE_URL的拼接方式HTTPS 页面跳到 HTTP 地址被拦截服务端基于请求Host拼地址Host被代理改成内网形式检查反代配置确认Host头是否被重写外部访问时Location是内网 IP网关层改写了上游返回的Location逐层抓包对比原始响应头和代理转发后的响应头CDN 缓存后跳转地址不对上游返回相对Location不同缓存节点基于不同入口解析确认源站返回绝对地址关闭对跳转响应的缓存6. 从这次排查里带出的几条习惯我现在接手任何一个 Web 项目第一件事就是查代码里所有重定向的生成方式。只要看到redirect、Location相关的地方还在手工拼字符串我都会顺手改成统一的跳转工具函数。这不是小题大做日志里每次出现跳转异常最后定位到Location头的概率高得惊人。多说一句Location头写相对路径还是绝对路径标准上已经给了明确答案但线上环境教会我的真理是不要赌客户端的兼容性。我个人的经验是凡是服务端生成的Location一律输出绝对地址凡是相对路径的使用场景限定在服务端内部做拼接最终给到客户端的永远是一个完整的 URI。这看起来保守但至少能让你少熬几次凌晨三点的排查夜。