S27-A01 · 内网穿透与联调

适用读者：本地开发要接收第三方回调（支付/微信/Webhook）的人。
前置：S15-A01（Nginx）。
覆盖旧文：433(262) = 262 点。
扩展点：E-S27-016（穿透的安全边界）。
上一篇：S27-J06 · RAG 提效与数据流水线
下一篇：S27-A02 · 多模态生成。

1. 一句话结论

内网穿透把"外部回调"引到本机，代价是把本机端口暴露到公网——所以它只该用于开发联调，绝不能带真实凭据。

第三方 → 公网入口（穿透服务）→ 隧道 → 本机 dev 服务

方案	特点
隧道服务（ngrok 类）	一条命令、临时域名
自建（frp）	可控、要服务器
反向代理到测试环境	更接近生产

2. 安全边界（E-S27-016）

红线	原因
不用生产密钥	隧道流量经第三方
不在穿透环境跑真实数据	数据出境
用完即关	暴露面越小越好
加基本校验（签名/白名单）	防误触发

判据："这个回调里有没有真实用户数据？" 有 → 用测试环境，别用穿透。

3. 联调常见坑

现象	原因
回调收不到	第三方要求 HTTPS/公网可达
回调重复	对方重试 + 你未幂等（S27-B04）
签名校验失败	时间戳/编码/密钥环境不一致
本机重启后失效	隧道域名变化，要重配回调地址

4. 更接近生产的做法

做法	好处
部署到测试环境	网络与证书一致
用测试商户号/沙箱	不碰真实资金
灰度回调地址	可切换

5. 五个误区

误区	真相
"穿透能替代测试环境"	网络差异大
"隧道很安全"	流量经第三方
"用生产密钥方便"	高风险
"本地重启没关系"	回调地址会变
"签名失败是对方问题"	常是本机环境差异

6. 自检（架构师版）

三种穿透方案？
四条安全红线？
四个联调常见坑？
为什么"穿透不能替代测试环境"？
签名失败常见原因？

7. 下一篇

S27-A02 · 多模态生成：视频与素材流水线

穿透讲完，下一篇讲生成式内容怎么进工程链路。

本篇属于系列《S27 · 杂项归档与工具实测》。旧文来源：A-433；扩展点 E-S27-016。