测试第三方 API 时，通常先配置代理来处理出站请求，这一步很快就能完成。之后同一个服务商发来 webhook——订单已支付、任务已完成之类的回调通知——数据却怎么也收不到。下面说明为什么这与代理无关、断裂到底出在哪里，以及如何搭建一套不依赖出站通道的回调接收方案。
代理只改变出站路径，不会打开入站入口
代理只出现在出站这一段：由你发起连接，代理替换请求对外呈现的返回地址和 IP，之后收到的一切都是对这条已建立连接的响应。Webhook 的方向相反——发起方是服务商，而不是你。它会向你事先在后台或参数里登记的 URL 主动建立一条新连接，这条连接与你刚才访问其 API 所用的通道毫无关系。
由此产生一个常见误解：换了出站通道，就以为回调也会随之改变。实际上，入站请求的路径只取决于接收地址指向哪里、该地址能否从外部访问，与你自己用什么发起出站请求完全无关。
回调收不到的真正原因
Webhook 丢失的原因不多，而且都出在接收端。设备处于家庭或办公室路由器的 NAT 之后且未做端口映射，从外部看这个地址根本不存在。本地开发环境的地址在公网上无法解析。登记的 URL 指向只能在内网访问的主机。TLS 证书过期或域名不匹配，握手在正文送达前就已失败。服务器返回非 2xx 状态码，多数服务商在几次失败后就会停止重试。
另一个常见原因是服务商自身的白名单：基础设施变更后没有同步更新记录，回调便悄无声息地失败，双方都看不到明确报错。
如何正确接收回调
接收端必须是公网可达的地址，开放端口并配有有效的 TLS 证书——服务商能够直接连接的域名或 IP，你这边无需任何代理或隧道。这个要求与你调用同一个 API 时使用哪种出站通道毫无关联。
合理的架构会把「确认收到」与「处理数据」拆成两步：轻量处理器先把原始请求体存入队列，立即返回 200，不等待业务逻辑跑完；处理逻辑另起进程异步执行。这样能避免服务商侧超时——一旦处理耗时超过响应窗口，同步方案迟早会在负载升高时丢事件。
如果确实无法开放公网地址——封闭网络、测试环境、临时环境——就改用轮询代替推送：多数支持 webhook 的 API 都提供并行的状态或事件查询接口，按计划定时查询即可。延迟会从秒级拉长到轮询间隔，但对公网可达性的要求就此消失。
如何核实送达
核实要看两份独立日志，而不是一份。第一份是服务商后台的送达日志，记录尝试次数、响应码和时间点。第二份是你自己接收端的日志，用来证明请求确实到达了你的代码，而不是被负载均衡或 CDN 直接以 200 应答拦下、正文没有继续传递。服务商显示「已送达」而你的队列里没有对应记录，说明中间某处断裂，而不是集成已经跑通。
还要核对签名：如果 webhook 用 HMAC 密钥签名，而你这边保存的密钥在轮换后已经过期，服务器会把合法事件当作伪造静默拒绝——外部表现和「没收到」完全一样。
代理在这套流程里仍然有用的地方
代理在出站这一段依然有价值。如果你改用轮询，每次查询都是一次出站请求，可以像访问任何第三方服务器一样按地区、按频率分配，并在触发限速时轮换地址。另一个场景是核实平台在指定国家看到的结果：如果回调逻辑依赖服务商的地域判断，从匹配的地区去验证会比默认的数据中心地址更可靠。
常见问题
可以通过代理接收 webhook 吗？
服务商需要直接连到你的接收端，你用于出站请求的通道在这条链路里不起作用。如果要隐藏服务器真实地址，应在其前面部署反向代理——这是另一种角色，不要与用于出站调用第三方 API 的代理混淆。
为什么后台显示「已送达」，但数据没有收到？
「已送达」只表示服务商收到了来自你地址的 2xx 响应，可能是负载均衡、CDN 或同域名下的其他服务代为应答，并未把正文传给队列。应对照服务商日志与自己接收端的日志，而不是只信后台状态。
完全无法开放公网地址怎么办？
改用轮询：按计划定时查询状态接口，而不是等待推送通知。延迟会增加，但对公网可达性的要求随之消失。
这套流程的出站部分——定时查询服务商 API，或核实回调在指定国家的表现——适合从代理专区选择专属或轮换通道。配置方法见按 API 配置 IP 轮换，通道质量指标见如何核实代理质量。