达美航空机票查询工具（Akamai 风控 + 链式代理）产品系统

差旅公司、机票代理和比价工具需要按航线与日期批量查询航班和票价，用于报价、监控和路线分析。达美官网的报价接口有 Akamai 风控：缺少访客请求头直接 401，缺少完整传感器 cookie 或出口是机房 IP 直接 444，动态住宅 IP 不固定会话会一直卡在 429。业务要求能稳定按参数查询并输出结构化结果，所以核心不是解析页面，而是把访问链路做对。

1）参数化查询：输入出发地、目的地、日期，可选往返、成人数，支持三字码与英文城市名，内置机场补全；
2）风控链路：按门一到门三逐项处理——补 Authorization: GUEST、注入浏览器导出的整套 Akamai cookie、住宅 IP sticky 会话、curl_cffi 对齐 TLS 画像；
3）链式代理：自研本机 HTTP 代理，把「本机 → 海外跳板 → 住宅网关」两段 CONNECT 串起来，TLS 端到端协商，指纹不被中间层破坏；
4）协议查询：调用 GraphQL gqlSearchOffers，按报价集翻页，2.5 秒间隔，444/429 明确判定并给出排障提示；
5）结果解析：输出航班、起降时间、经停、时长、票价、币种、是否售罄、报价 ID，单程与往返都支持，币种按出发地市场推断；
6）交付：CSV/JSONL/运行摘要/原始响应快照，cookie 规范化与可用性验证脚本，39 项离线单测支持 fixture 回放。

我独立完成风控排查、协议还原、工程实现与验收。①先做对照实验定位门禁：同一 IP 下分别去掉请求头、逐个减少 cookie、换机房/住宅出口、换 TLS 画像，确认「Authorization: GUEST + 完整 Akamai cookie（含 HttpOnly）+ 住宅 sticky IP + 对齐的 TLS 指纹」四者缺一不可，并把 444/429/401 三类失败区分开。②发现动态住宅默认每连接换 IP，页面加载与传感器上报落在不同 IP 上，_abck 永远过不去；改用隧道商的 sticky 参数固定出口后稳定 200。③住宅隧道商拒绝中国大陆直连（456），而 curl_cffi 没有 --preproxy、系统 curl 的 TLS 栈又过不了 Akamai，于是自写一个极小的 HTTP 代理，把两段 CONNECT 串起来，只隧道字节、不碰 TLS。④工程上用 curl_cffi 发请求，cookie 规范化脚本支持三种导出格式并真发一次请求验证可用；解析层兼容字段给对象/给数组两种形态，币种按出发地推断；39 项离线单测覆盖单程、往返、售罄与 GraphQL 错误。⑤验收：PEK→LAX 单程 153 条、往返 153 条、LAX→JFK 450 条，最低价与页面一致，退出码区分成功/风控/参数错误。