HTTP协议、令牌与跨域：前后端联调中的401和CORS排查指南

用户甲·2026-08-31·阅读 24 GEO检测（免费）

HTTP协议令牌JWT

|难度：普通|阅读约 31 分钟

很多人第一次被 HTTP、令牌和跨域这三个词同时缠住，通常都是在前后端联调的时候：浏览器控制台先给你一个红艳艳的 CORS 错误，你还没搞明白怎么回事，后端日志里又冒出一句 401 Unauthorized: 未提供令牌。我在带新人时经常看到这种画面——代码写得没问题，但就是卡在这一层"协议规则"上。

这篇文章就围绕 Http协议与令牌[跨域问题] 这个组合展开，把这三件事拆开揉碎：先讲 HTTP 状态码和令牌在请求里到底怎么工作，再讲 JWT 和刷新令牌的生存周期，然后深入跨域问题的本质，最后用一整章走一遍完整的排查链路。内容主要面向正在做前后端分离项目的开发同学，也适合刚接触 Web 接口调试、被 401 和 CORS 反复折磨的测试或运维朋友。

1. 先拆报错："401 未提供令牌"到底是谁在说话

1.1 HTTP 状态码不是后端发明的，是协议规定的

所有 Web 接口调试，最后都要落到 HTTP 协议上。HTTP 是应用层协议，构建在 TCP/IP 之上，和 FTP、SMTP 这些老牌协议一样，都在解决"两台机器之间怎么约定格式"的问题。FTP 管文件传输，HTTP 管超文本和通用资源传输，而像令牌、跨域这些概念，其实都是沿着这条协议链路一步步长出来的。

先说 HTTP 状态码。很多人以为 401、403 这些状态码是后端代码里 return 401 写出来的，这个理解没错，但容易忽略一个关键点：状态码的语义是 HTTP 协议规定好的，后端只是按规矩填数字。401 Unauthorized 表示"请求缺少身份验证凭证，或凭证无效"，它和 404、500 一样，有自己的标准含义。

这就解释了为什么前端迟迟没有收到数据时，后端日志却先出现一行 unexpected status 401 unauthorized: 未提供令牌。这行日志大概率是后端网关或拦截器打的，它的意思不是在骂你，而是告诉你：令牌（Token）没送到，或者送到了却解析不了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

1.2 令牌应该放在哪里，才能让服务器认出你

令牌这东西，通俗说就是你在服务器那里领到的一张"临时通行证"。HTTP 协议是无状态的，服务器默认不记得你是谁来过，所以你需要每次请求都主动喊一句"我是谁，我的通行证在这里"。

最常见的携带方式是放在请求头（Header）里，标准字段名是 Authorization，格式一般是：

code复制Authorization: Bearer <token>

Bearer 这个词的意思是"持有者"，服务器看到这个前缀，就知道后面那一长串字符串是令牌。我曾经见过有人把令牌塞在请求体里、塞在 URL 参数里，虽然也能传，但都不符合惯例，而且很容易让日志把令牌泄露出去。

服务器收到令牌之后，会做两件事：验证签名、检查有效期。验证签名是为了确认这个令牌确实是服务器自己签发的，没有被篡改；检查有效期是为了防止令牌无限期使用下去。如果你没带令牌，或者带的令牌过期了、格式不对，服务器就会回 401 Unauthorized，日志里自然就出现"未提供令牌"或者"无效令牌"这类提示。

1.3 401和403的区别，以及"未提供令牌"的几种变体

401 Unauthorized 和 403 Forbidden 经常被混在一起，我面试时很喜欢问这个，因为十个人里至少有五个答不清楚。它们有一个很核心的区分：

401：你还没证明你是谁（没令牌、令牌无效、令牌过期）。
403：你已经证明你是谁了，但你没有权限做这件事（令牌有效，但角色不够）。

也就是说，401 的解决方式是"去换一个合法令牌再请求一次"，而 403 的解决方式是"找管理员加权限"。

在实际项目里，"未提供令牌"这条信息还有很多变体。比如有的网关会返回 Missing authentication token，有的是 Token has expired，还有的会带上一个 request id，像那段日志里一样。request id 是很有用的东西，它相当于这次请求的身份证号，排查问题时可以拿着它去网关或后端日志里精确搜索，快速定位到具体是哪个环节把令牌弄丢了。

2. 令牌的一生：从签发、携带到撤销的难点

2.1 JWT三段式结构：为什么说它是"带签名的JSON"

现在主流项目里用的令牌，绝大多数是 JWT（JSON Web Token）。JWT 长这样：

code复制eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywiZXhwIjoxNzAwMDAwMDAwfQ.sQd5L8LxJvRwS5z_8m7rA

它不是随机字符串，而是三个部分用点号拼起来的 JSON 数据。第一部分是头部，声明签名算法；第二部分是载荷，放用户信息、过期时间这些业务数据；第三部分是签名，用来防止前两部分被篡改。

我习惯把 JWT 理解成"带签名的 JSON"。为什么强调签名？因为 JWT 的载荷默认只是 base64 编码，不是加密，任何拿到令牌的人都能把这个 JSON 解出来看内容。真正保证它不可伪造的，是服务器端用密钥算出的那个签名。

这种设计的最大优点是服务端不需要存会话状态，拿到令牌直接验证签名就能认出用户，非常契合分布式系统和微服务架构。但由此也引出一个让大家头疼的问题：撤销难。

2.2 轮换刷新令牌与离线撤销的取舍

JWT 一旦签发出去，在到期之前几乎没法让它提前失效（除非服务端额外维护黑名单）。比如用户改了密码、账号被封禁，服务端想作废旧令牌，就不得不保存一份"失效令牌名单"，每次请求都查一下。这等于把无状态的 JWT 又做成了有状态，治标不治本。

所以行业内普遍采用一个折中方案：把令牌分成两种——访问令牌（Access Token）和刷新令牌（Refresh Token）。访问令牌有效期很短（比如 15 分钟到 2 小时），用于正常的接口访问；刷新令牌有效期很长（比如 7 天到 30 天），只在访问令牌过期后单独发一个请求去换新的访问令牌。

这就像一个"脏衣服"策略：贵重物品（访问令牌）随身带，丢了损失可控；备用钥匙（刷新令牌）放在保管箱里，过期后再去领新的。真要撤销时，只要把刷新令牌作废，访问令牌短时间后自然过期，问题就能控制住。

Pixeval（一个第三方图片浏览器工具）会问"刷新令牌怎样获取"，其实很多第三方应用也是这个套路：先用某种授权码换刷新令牌，再拿着刷新令牌去换访问令牌。你在登录一个第三方应用时，看到的"授权"页面，本质就是在走这个流程。

2.3 一个容易被忽略的细节：时间戳与时钟漂移

JWT 载荷里通常有两个时间字段：iat（签发时间）和 exp（过期时间）。签发令牌的服务器和验证令牌的服务器，都需要依赖系统时间去判断有效期。

但分布式系统里有个隐蔽的坑叫"时钟漂移"：如果签发令牌的服务器时间比验证服务器慢了 5 分钟，那么新签发的令牌在验证服务器眼里可能一出生就过期了，客户端会收到莫名其妙的 401。我碰到过一次，排查了半天，最后发现是某台内网服务器时间同步服务出了问题。

比较稳妥的做法是给验证逻辑加一个很小的宽容窗口，比如允许令牌在有效期内额外加 30 秒到 5 分钟的余量。别小看这个容差，在多个服务节点共用同一套密钥、但各自系统时间不完全一致的环境下，它能把很多"灵异"的过期问题直接抹平。

3. 跨域问题不是服务器不让你调，是浏览器在把关

3.1 同源策略的真实目的，以及iframe跨域为什么特殊

跨域的全称叫"跨源资源共享"，它的根源在浏览器的同源策略（Same-Origin Policy）。同源的定义是：协议相同、域名相同、端口相同。只要有一个不同，就算跨域。

很多新手下意识认为跨域问题是后端在"刁难"前端，其实浏览器才是真正的守门员。服务器把数据正常返回了，但浏览器发现响应头里没有允许跨域的声明，就会直接拦下来不交给页面 JS。这就像快递把包裹送到门口，保安（浏览器）看你不是本栋楼的人，就替你拒收了。

iframe 跨域问题在这里面比较特殊。iframe 标签天然可以加载任意域的页面，但子页面和父页面之间如果不同源，访问对方的 DOM 会被严格限制。有些项目想在页面里嵌一个第三方 H5 页面，然后通过 postMessage 通信，结果总是对不上。其实 postMessage 是允许跨域的，但双方必须约定好消息格式，并且一定要校验 event.origin，防止其他网站给页面乱发消息。很多安全问题，都是因为开发者偷懒不校验 origin 导致的。

3.2 CORS预检请求：为什么OPTIONS请求突然变多

跨域请求分两类：简单请求和预检请求。简单请求只需要浏览器在请求头里加上 Origin，服务器返回 Access-Control-Allow-Origin 就能通过。但如果请求使用了 Authorization 头、自定义头或者 PUT、DELETE 等方法，浏览器会先自动发一个 OPTIONS 请求，叫做"预检"。

预检请求的目的是问服务器：我真正要发起的这个请求，你允许吗？只有预检通过，浏览器才会发送真正的业务请求。我之前排查过一个问题：后端接口明明正常，文档也写了支持跨域，但前端就是报 CORS 错误。打开 Network 面板一看，所有 OPTIONS 请求返回的响应头里都缺少 Access-Control-Allow-Headers，导致 Authorization 头根本没被允许。浏览器以为是安全问题拦下来，后端自己倒是一脸无辜。

所以遇到跨域报错，第一件事不是去改代码，而是去浏览器 DevTools 的 Network 面板里看请求和响应头，特别是 OPTIONS 请求的响应头。缺少哪个 Allow 头，就在后端加上哪个。

3.3 SpringBoot里配置CORS的几种姿势

以 Java 后端常用的 SpringBoot 为例，解决跨域问题有三个常见层面。

第一种，用注解，适合单个接口：

java复制@CrossOrigin(origins = "http://localhost:5173")
@GetMapping("/api/user")
public User getUser() {
    return userService.getUser();
}

第二种，配置全局策略，适合整个项目统一处理：

java复制@Configuration
public class CorsConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/api/**")
                        .allowedOrigins("http://localhost:5173")
                        .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                        .allowedHeaders("*")
                        .allowCredentials(true)
                        .maxAge(3600);
            }
        };
    }
}

第三种，是使用 Spring Security 时容易踩坑的情况。如果项目里加了 Spring Security，光配 CORS 还不够，因为安全过滤器链会在 CORS 之前拦截请求。你需要单独注册一个 CorsFilter 到 Security 过滤链里，并且放行 OPTIONS 请求。很多 SpringBoot 项目跨域配了半天没生效，最后查出来都是 Security 拦截器把 OPTIONS 请求都挡掉了，前端根本走不到 CORS 处理那一步。

关于 allowCredentials(true) 要注意：它开启后，allowedOrigins 不能写 *，必须写具体的域名。这是浏览器的安全规定，如果你非要允许带 Cookie 的跨域请求，就得把域名白名单列出来，不能图省事全用通配符。

3.4 火狐浏览器和Chrome在跨域调试上的差异

有同学会问"火狐浏览器设置跨域问题"怎么处理，我理解他的意思可能是：同一个接口在 Chrome 里能调通，换到火狐就报错，是不是火狐有什么特殊设置？

事实是，现代浏览器的同源策略和 CORS 实现基本一致，如果同一套代码在 Chrome 能通、在 Firefox 不能通，多半是下面几个原因：

你会话里存的令牌、Cookie 在两个浏览器里不一致，Firefox 环境里根本没有有效登录态，所以先被 401 挡了。
Firefox 有更严格的隐私保护设置，比如"严格模式"下会阻止某些第三方 Cookie 或跟踪器，间接影响了跨域请求携带凭据。
你使用了浏览器插件，比如流量代理、安全插件，这些插件在 Firefox 和 Chrome 上的行为可能完全不同。

所以遇到"火狐跨域报错"，不要一上来就改代码，先按"同一份请求在两个浏览器里对比"的思路排查。用开发者工具的"复制为 cURL"功能，把两个浏览器的请求原样复制到命令行里跑一下，结果一样的话，就是浏览器环境差异，不是代码问题。

4. 令牌+跨域叠加时的排查清单与修复顺序

4.1 一个典型的全链路报错现场

讲单独的概念容易，难的是这些事同时发生。我给你描绘一个我见过很多次的现场：

前端项目跑在 http://localhost:5173，后端接口在 http://localhost:8080。前端登录后拿到了一个 JWT，然后发请求去查询用户资料。浏览器控制台先报 Access to XMLHttpRequest at 'http://localhost:8080/api/user' from origin 'http://localhost:5173' has been blocked by CORS policy，紧接着后端日志又出现 401 Unauthorized: 未提供令牌。

新手一看到两个报错就慌了，其实这两个报错往往是同一次请求的两个侧面。可能是前端压根没把 Authorization 头带上，也可能是请求被 CORS 预检挡了，根本没发到后端。这时候顺序很重要：先看 Network 面板里有没有实际发出请求。

4.2 排查步骤：先解决CORS，还是先解决401？

我的习惯是分三步走。

第一步，在 Network 面板里找到失败的请求，看 URL 和请求头。如果 Authorization 头不存在，问题在前端，返回去检查拦截器、axios 配置或者 token 读取逻辑。

第二步，如果 Authorization 头存在，但请求还是 401，把令牌复制出来，到 jwt.io 或后端写个测试接口解析一下，看是否过期、签名是否合法。

第三步，如果请求头没问题、后端也返回了数据，但浏览器报了 CORS 错误，那问题就是后端响应头配置不对，去看 Access-Control-Allow-Origin 和 Access-Control-Allow-Headers 是否匹配。

实际业务里，"先解决哪个"没有固定答案，但有一个原则可以帮你快速缩小范围：用 cURL 模拟同一个请求。cURL 不经过浏览器，不受 CORS 限制，如果 cURL 能拿到数据而浏览器拿不到，说明问题一定出在跨域配置上；如果 cURL 也拿不到，那就是令牌或后端业务的问题。

4.3 那些"诡异"的失败：Authorization头被吃掉、凭据被清空

排查多了之后，你会发现不少"诡异"现象其实都有规律。

比如在某些代理服务器或网关里，Authorization 头会被过滤掉。我曾接手过一个老项目，前端明明发了 Authorization 头，后端收到的却为空，查了很久才发现是 Nginx 配置文件里的 proxy_set_header 没有把该头透传。这种问题从应用层日志看不出来，得看网关或 Nginx 的真实转发请求。

还有一个常见坑：使用 fetch 时，如果开启了 credentials: 'include'，跨域请求处理 Cookie 和 Authorization 头的方式会和默认情况不同。有时候你把 credentials 打开了，但同时后端 allowedOrigins 又用了通配符 *，浏览器会直接拒绝响应。这不是令牌的问题，而是 CORS 配置和凭据配置冲突。

另外，单点登录系统里经常出现"登录成功但后续请求全部 401"的情况。原因往往是刷新页面后 token 只存在内存里，页面一刷新就丢了。解决办法是把 token 放到 localStorage 或 sessionStorage，在应用初始化时读取后再挂到请求头里。要注意 localStorage 存在 XSS 风险，敏感项目建议用 HttpOnly Cookie 方案，但 Cookie 方案又会引入 CSRF 问题，这就是另一个话题了。

4.4 遇到"登录失败：检查API令牌或GitLab版本"这类提示时怎么定位

除了前后端联调，集成第三方系统时也会遇到令牌问题，比如某次用 Git 客户端登录 GitLab，提示"登录失败。请检查 API 令牌或 GitLab 版本（如果版本低于 14.0）"。

这种报错的关键词是"API 令牌"和"版本"。GitLab 从某个版本开始，对 API 令牌的认证方式做了调整——如果你用的旧版本 GitLab 不支持某种令牌格式，或者你复制的是个人访问令牌而不是 OAuth 令牌，登录就会失败。

我的排查顺序是：先确认 GitLab 版本是否满足要求，再检查令牌类型是否匹配（个人访问令牌、项目的访问令牌、OAuth 令牌完全是三回事），最后看令牌是不是有足够的权限范围。很多人把"有令牌"直接等价于"有权限"，但令牌的权限范围往往是独立的，比如只允许读仓库、不允许写仓库。这时候报的错可能不是 401，而是 403。

这个过程和 HTTP 鉴权的整体思路是一致的：协议负责规定"携带什么凭证"，服务端负责规定"什么样的凭证有效"，而前端要做的是把正确的凭证、以正确的方式放到正确的位置。三者匹配，数据自然就通了。

5. 令牌与跨域联动时的安全细节与设计建议

前面提到令牌可以放 Authorization 头，也可以放 HttpOnly Cookie。这个选择不仅影响跨域配置，还直接影响安全边界。

放在 Authorization 头的优点是显式、可控，前后端分离时非常好调试；缺点是无法做到 HttpOnly，如果因为某种原因被 XSS 脚本读到，令牌就可能被窃取。放在 HttpOnly Cookie 的优点是浏览器会自动携带，JS 拿不到，能有效防 XSS 盗取；缺点是要应对 CSRF 攻击，并且跨域携带 Cookie 时需要配置 credentials: 'include'，后端也要把 allowCredentials 打开。

我一直以来的建议是：如果项目有前后端两个完全独立的域名，优先用 Authorization 头方案，配合短时长的访问令牌和刷新令牌互相补充，因为调试成本低，跨域配置也更好控制。如果项目对安全等级要求特别高，或者前端页面和 API 在同一主域下，再考虑 HttpOnly Cookie 方案，并且额外做 CSRF Token 防护。

5.2 精确的 CORS 白名单比"全放通"更省心

CORS 配置虽然简单，但很多人图省事，直接在 allowedOrigins 里写 *，配合无凭据模式也能工作。可一旦你后面需要带 Cookie，就得把所有可能的前端域名都列出来。我见过一个项目因为域名列表写得不全，线上环境手机端能访问、PC 端不能访问，最后发现是漏了 https://www.xxx.cn 和 https://xxx.cn 两个不同写法。

这里的经验是：CORS 白名单要按"环境"规划。开发环境可以放宽一点，用 http://localhost:* 或者动态读取缓存配置文件；生产环境必须精确匹配。如果你有多个前端域名，比如管理后台、用户端、供应商端，建议分不同规则，或者在后端配置类里单独维护一个 List<String>，用配置文件注入，这样将来加域名不用改代码，改配置重启就行。

5.3 把 401 和 CORS 错误的处理逻辑提前设计好

一套健壮的体系，不能只靠"报错了再查"。我建议你在项目启动阶段就把这两个东西设计进全局逻辑里。

在前端，axios 拦截器里统一处理 401：跳转到登录页、清除本地缓存的令牌、提示用户重新登录。同时要区分"这个请求是否真的需要令牌"，比如登录接口本身就不能被拦截器当成 401 跳转，否则就死循环了。做法是先判断 URL 是否在白名单里，再决定要不要加 Authorization 头。

在后端，统一处理跨域和令牌校验的顺序。如果用了 Spring Security，务必把 CorsFilter 放在认证过滤器之前。这样即使令牌无效，浏览器也能先拿到正确的 CORS 响应头，前端才能读到 401 的 JSON 体，而不是被 CORS 错误挡住，连错误信息都看不到。这个顺序错位，是很多团队排查到凌晨的元凶。

6. 我在实际项目里踩过的几个令牌与跨域坑

最后分享几个真实踩坑记录，不一定每个人都会遇到，但遇到了可以少走很多弯路。

第一个是"生产环境跨域正常、测试环境全部 401"的问题。后来发现是测试环境的前端域名最近改过一次，但后端配置文件的 allowedOrigins 没更新，新域名发起的请求全被浏览器拦了。当时日志里没有任何 401，因为请求根本没到达后端。看似是令牌问题，实则是跨域配置问题。

第二个是"刷新令牌一直在换，但访问令牌还是过期"的问题。检查后发现前端在并发请求时，两个请求同时发现访问令牌过期，于是同时去刷新，其中一个刷新成功，另一个因为刷新令牌已轮换而失败。解决方案是给刷新操作加一个互斥锁，保证同一时间只有一个刷新请求在跑，另一个请求等刷新完成后重放。

第三个是"GitLab 集成登录时，明明复制的是 API 令牌，还是报 401"的问题。后来发现是令牌前面多复制了一个空格。这种低级错误看起来离谱，但在真实联调里真的很常见。以后凡是复制令牌，先看一眼首尾有没有多出来的空白字符。

说实话，Http协议、令牌和跨域这三件事，单独拎出来都不算难，真正难的是它们组合在一起时那种"处处受限"的窒息感。我自己的体会是：不要上来就改代码，先养成看请求头、响应头、状态码的习惯，再配合 cURL 和 Network 面板做对照实验，绝大部分问题都能在十分钟内定位到根因。等你把这套排查节奏练熟了，再去谈安全和性能优化，就会发现它们是水到渠成的事。