广告落地页多国核查怎么配出口IP：按任务分轮换粒度，再定国家参数和验证口径

做多国广告落地页核查，出口IP的选型判断可以先压缩成三句话：

出口必须是真实住宅网络，机房IP段在很多广告系统和伪装脚本那里是被单独对待的，你看到的可能不是当地用户看到的页面。
多国分散抽检用动态住宅流量套餐，按流量计费、按国家指定出口，覆盖几十上百个地区的成本最低。
跟踪完整跳转链路时必须开粘性会话，从广告点击到追踪域名再到最终落地页，全程同一个出口IP。

剩下的都是配置和验证细节。下面按你实际要做的事展开。

先分清你在核查什么

“广告落地页多国核查”其实是两类任务，它们对出口的要求正好相反，混在一套配置里跑就会互相拖累。

任务A：多国覆盖抽检。 你要知道同一条广告在 20 个国家分别展示了什么、跳到了哪里、页面语言和货币对不对、有没有地区被重定向到错误版本。特点是国家多、每个国家采样次数不多、单次只加载一两个页面。这类任务希望出口尽量分散，每次检测换一个出口反而更接近真实分布。

任务B：单条链路完整跟踪。 你怀疑某个投放渠道对检测流量和真实流量返回了不同页面，需要把“曝光点击 → 追踪归因域名 → 中间跳转 → 最终落地页”整条链路一次性跑完，并把每一跳的响应都留证。特点是一次会话里有多个连续请求，中途换IP就会毁掉这次取证。

这两类任务的出口都来自同一个动态住宅池，区别只在轮换粒度：A 用每请求或每次任务轮换，B 用粘性会话。别用一套参数跑全部。

为什么机房IP会让核查白做

这一条是选型的前提，不是可选项。

广告投放链条上的伪装（cloaking）脚本、反欺诈系统、以及很多广告主自己的合规检测，都会在第一跳就判断来访IP的归属类型。对数据中心IP段，常见处理是：直接拒绝、返回一个完全合规的“白页”、或者跳过地域分流逻辑给一个默认页面。你拿这样的结果去做核查，结论是反的——页面看起来一切正常，恰恰因为对方知道你不是真实用户。

所以核查出口的第一判据是 ASN 属性，而不是“IP 显示在哪个国家”。IP 定位数据库说它在德国，但 ASN 属于某个云厂商，那它在检测方眼里依然是机房流量。这一点在后面的验证步骤里要单独查。

计费口径：先按流量估，什么时候换带宽

多国核查的流量结构很有利于按流量计费：一个完整网页（含图片和脚本）通常在几兆的量级，如果你只取 HTML 和跳转头、禁掉图片和视频，单次检测的消耗还会小一个数量级。国家多不等于流量大，真正吃量的是加载策略。

估法很简单：拿三个有代表性的目标页面，用无头浏览器按你实际的加载配置各跑一次，记录实际传输字节；乘以你的国家数和日巡检频次，再留一倍余量给重试和失败请求。算出来如果是几十 GB 的月量级，按流量计费更划算。

什么时候该换按带宽计费、不限流量的口径？两种情况：一是你把落地页录屏、全资源加载、截图对比做成了常态，单次消耗从几兆涨到几十兆；二是你的巡检是高并发持续跑的，并发通道数稳定、流量曲线平坦。这时按带宽算总成本更可控，也不用天天盯余量。具体估算口径可以参考动态住宅流量套餐的用量怎么估里的采样方法。

对应到产品上：多国抽检和常规链路核查从动态住宅流量套餐起步，它同时支持轮换和粘性两种会话模式，正好覆盖上面的任务A和任务B；等巡检规模稳定、流量明显上台阶，再评估切到动态住宅带宽套餐。

粘性会话与每请求轮换在广告跳转链路中的区别

国家参数和接入方式怎么配

传国家

动态住宅池指定地区一般有两条路：

账密认证：在用户名字段里按服务商规定的格式拼接国家代码（通常是 ISO 两位码）和会话标识，一条链路对应一组凭据。优点是脚本里直接换字符串就能切国家，适合几十个国家并行。
API 提取：调接口按国家取一批出口，再把返回的地址喂给脚本。适合需要先拿到IP清单、做去重和黑名单管理的场景。

两者的差别和各自适合的工程形态，可以看API提取和端口转发有什么区别。具体字段名和拼接顺序各家不同，以你所用服务商的面板说明为准，不要照抄别处的示例串。

认证方式上，多国核查通常跑在云上、出口IP不固定的调度机器上，账密认证比白名单更省事；只有当你的执行机有稳定固定的公网IP、又想省掉凭据管理时，白名单才更顺手。判断维度见账密认证和白名单认证怎么选。

协议和并发隔离

HTTP/HTTPS 足够应付绝大多数页面抓取；如果你的检测客户端要走非 HTTP 流量，或者需要在系统层统一代理，SOCKS5 更合适。

关键是每个国家一条独立通道：独立的会话标识、独立的 Cookie 容器、独立的浏览器上下文。共用上下文最容易出的事故是，A 国检测留下的 Cookie 或 localStorage 被 B 国的请求带上，落地页按旧地区分流，你看到的结果和真实用户完全不同。

粘性会话别只设一半

任务B 里，粘性会话要覆盖的是“整条跳转链路”，而不是“第一个请求”。常见漏配：HTTP 客户端开了 follow redirects，但每次跳转重新建连时会话标识没带上；或者浏览器只给首个导航请求走了代理，页面内的 XHR 走了别的通道。配置完要用同一会话连发多次请求核对出口是否一致，参数规范和几个典型漏点在粘性会话怎么设置才不会中途掉登录态里列得比较全。

到手怎么验：五步

配好别急着批量跑，先用一个国家走完下面五步，确认没问题再铺开。

第一步，查归属地和 ASN。 通过代理访问一个返回 IP 详情的接口，同时看三项：国家是否等于你传的参数、ASN 名称是否是当地 ISP（而不是云厂商或托管商）、是否被标记为代理/托管类型。国家对但 ASN 不对，这条出口对广告核查就是不可用的。城市级、ASN 级定向的填法和验法可以参考城市定向和ASN定向怎么填、到手怎么验。

第二步，验会话一致性。 同一会话标识连发 5 次请求，出口IP 必须完全一致；换一个会话标识再发，IP 应该变化。两边都符合预期，粘性和轮换才算都配通了。

第三步，跑一次完整链路并留证。 关掉自动跟随，手动逐跳请求，把每一跳的状态码、Location、响应头、最终 HTML 全部落盘，同时记录该次会话用的出口IP。这份记录才是你后面判断“是否存在地域错配或页面伪装”的依据；只存最终页面截图是不够的。

第四步，对齐浏览器环境。 出口IP 在日本、浏览器时区却是 UTC+8、Accept-Language 是 zh-CN、WebRTC 还泄漏了本机地址——这种组合在有反欺诈检测的落地页面前是明显矛盾。自动化环境里要把时区、系统语言、Accept-Language 跟随目标国家一起切换，并关闭 WebRTC 的本地地址暴露。这部分属于浏览器环境范畴，NexIP 只负责网络出口，指纹和环境隔离要靠 NexBrowser 这类工具配合。

第五步，设对照组。 同一个页面，分别用目标国住宅出口、本地直连、机房IP 各跑一次，比较三份结果。如果住宅出口拿到的页面与另外两者明显不同，说明你的检测确实穿透了分流逻辑，这套配置可以用了；如果三份一模一样，先别下“没有问题”的结论，多半是某个环节没生效。

脚本侧怎么把代理接进 Requests、HTTPX 或 Playwright，可以直接照着住宅代理接进Python采集脚本的配置实录改。