Postman 默认不自动匹配子域名 Cookie，必须手动设置 Domain 字段为 .example.com 才能使父域 Cookie 被子域请求携带；其严格遵循 RFC 6265 域名匹配规则，不补点、不模糊匹配。
Postman 默认不自动匹配子域名 Cookie，必须手动设置 Domain 字段才能让父域 Cookie 被子域请求携带。
为什么子域名请求带不上父域 Cookie
浏览器和 Postman 都遵循 RFC 6265 的 Cookie 域名匹配规则：若响应头 Set-Cookie 中的 Domain 属性为 .example.com（开头带点），则该 Cookie 可被 example.com 及其所有子域（如 api.example.com、admin.example.com）使用；若只写 example.com（无前导点），则仅精确匹配该域名，不匹配任何子域。
常见错误现象：
- 登录接口返回
Set-Cookie: session=abc; Domain=example.com，后续请求发给api.example.com时 Header 里没有Cookie字段 - 在 Postman Cookies 管理器里看到 Cookie 已保存，但点击发送后请求头里没出现
根本原因不是 Postman “没保存”，而是它严格按 Domain 值做域名比对，不自动补点、也不做模糊匹配。
手动配置子域 Cookie 的两种方式
方式一：在 Cookies 管理器中显式填写带前导点的 Domain
- 点击请求右上角
Cookies按钮 - 点击
Add Cookie或编辑已有项 -
Domain字段填.example.com（注意开头的点） -
Path建议填/，否则可能因路径不匹配而失效 - 保存后，向
api.example.com、www.example.com等任意子域发请求都会自动带上
方式二：从响应头复制完整 Set-Cookie 字符串并 Bulk Edit
- 先发一次登录请求，查看响应头里的
Set-Cookie值 - 如果服务器返回的是
session=123; Domain=.example.com; Path=/; HttpOnly，就直接复制整行 - 在请求的
Headers标签页，点击Bulk Edit，粘贴为：Cookie: session=123 - ⚠️ 注意：这种方式绕过 Cookie 管理器，不依赖 Domain 匹配逻辑，但需手动维护值，无法自动更新
验证子域 Cookie 是否生效
最可靠的验证方式不是看 Cookies 管理器里有没有，而是检查实际发出的请求头：
- 发送一个子域请求（如
GET https://api.example.com/v1/user） - 点开
Console（底部状态栏左下角小图标），选Network标签 - 找到该请求 → 点开 → 查看
Headers→ 向下翻到Request Headers区域 - 确认存在
Cookie: ...行，且值与你设置的一致
如果这里没有，说明匹配失败；如果这里有但服务端仍报未登录，大概率是服务端校验了 Origin 或 Referer，和 Cookie 本身无关。
容易被忽略的细节
Postman 的 Cookie 管理器里显示的 Domain 列，是它“认为”该 Cookie 归属的域，不是你填进去的那个原始值 —— 它会自动把不带前导点的 example.com 转成 .example.com 显示，但这个转换不改变实际匹配行为。真正起作用的，始终是你在添加或编辑时手动输入的 Domain 字段内容。另外，Secure 属性开启后，Postman 只有在请求 URL 是 https:// 时才会发送该 Cookie，哪怕你正在测试 http://dev.example.com 也一样会被跳过。
