网站如何拦截非浏览器发起的请求？以Gusto登录页为例

你遇到的这种情况，网站能在首次请求就拦截非浏览器工具，主要是靠以下几种技术手段：

• TLS 指纹（JA3）识别：这是最核心的原因。浏览器和 curl、Postman 这类工具在发起 HTTPS 请求时，TLS 握手阶段的参数（比如加密套件优先级、扩展字段组合等）差异极大，网站可以通过 JA3 指纹快速区分真实浏览器和自动化工具。哪怕你复制了所有请求头，只要 TLS 握手的指纹不匹配，直接就会被打回 403。

• 请求头的细节校验：

  • 浏览器会自动带上 Sec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-Dest 这类规范头，这些头是浏览器导航请求的标识，工具默认不会发送，就算你手动复制，有些工具可能会过滤掉这些“非标准”头；
  • 部分网站会校验请求头的顺序，浏览器发送头的顺序是遵循规范的（比如先 Host，再 User-Agent，接着 Accept 系列），但工具往往会打乱这个顺序，触发校验失败；
  • 还有一些容易忽略的头，比如 Accept-Encoding 的具体编码组合、Connection 头的设置，工具和浏览器的默认值可能不一样，也会被检测到。

• User-Agent 深度校验：哪怕你手动设置了和浏览器一样的 UA，有些网站会做更细致的正则匹配，比如检查 UA 里浏览器版本号的格式、是否包含特定的子串（比如 Chrome 的 AppleWebKit/ 版本对应关系），只要有细微差异就会被拦截。

• IP/网络环境检测：如果你的浏览器和工具用的不是同一个网络环境（比如浏览器走公司代理，工具直接连公网），网站可能会基于 IP 归属地、是否在爬虫IP黑名单里进行拦截，哪怕是第一次请求。

验证方法参考：

1. 用支持自定义 JA3 指纹的工具（比如修改版 curl、或者 Playwright/Puppeteer 这类无头浏览器）模拟真实浏览器的 TLS 握手；
2. 把浏览器请求的所有头（包括 Sec-Fetch-*）完整复制，并且保持头的顺序和浏览器完全一致；
3. 逐字符核对 User-Agent，确保和浏览器发送的完全相同。

内容的提问来源于stack exchange，提问作者Nate