Apex 标注调用从 Salesforce 发出，而不是从你的 VPN 发出

笔记本上的 VPN 只给浏览器提供通路，不会给 Apex 或 Marketing Cloud 提供。请把真正的调用方与公网网关或合规的私有连接对应起来。

笔记本一接入 VPN，私有 API 就在浏览器里响应，于是这次集成似乎应该能跑通。但实际上跑不通，因为发起标注调用的代码运行在完全不同的地方。Apex 运行在 Salesforce 的应用服务器上，而 Marketing Cloud 的服务器端活动运行在该产品自己的运行时里。两者都不会继承你笔记本的隧道。请把它当成一段简短流程来处理：先确认调用方，再选择该调用方能够到达的入口，然后把通路端到端接通，最后从运行时自身进行验证。

在做任何网络改动之前先写好调用方卡片

把五个字段填满，并且拒绝猜测其中任何一个。执行产品与执行上下文决定了后续的一切，所以要从这里入手，而不是先动服务器的防火墙。

FieldWhat it must answer
RuntimeWhich product and execution context issues the request?
EndpointWhich hostname must that runtime resolve, and to what?
PathWhich supported public entry or private connection carries it?
IdentityWhich credential and which operation is the API asked to authorize?
FailureHow do responses return, and what happens when the path is down?

浏览器标签页和 Apex 标注调用是两个不同的客户端，浏览器能打开只证明从你的工位出发有一条通路。如果运行时字段写的是 Apex，那么相关的问题是 Salesforce 从哪些地址出网，而不是你笔记本持有哪些地址。正因如此，一条能让 API 在浏览器里加载的隧道，仍可能让集成以和之前相同的超时失败。调用方卡片存在的意义，就是在有人修改防火墙之前拦住这个错误。

选择调用方真正能用的入口

两种设计都合理，而且解决的是不同问题。第一种是刻意的公网入口：一个 HTTPS API 网关或集成服务，由它对调用方做认证、施加很窄的权限，并保持到私有后端的受保护连接。这和把每个后端服务都暴露出去、或把管理端口转发到互联网上不是一回事。

第二种是合规的私有连接。Salesforce 的Private Connect 出站文档介绍了如何通过绑定具名凭证的 Outbound Network Connection，在其既定的 AWS PrivateLink 安排之上路由受支持的标注调用。该功能在版本、许可和产品上都有约束，所以围绕它设计之前要先确认组织是否符合条件。

两种设计都不是装在 Salesforce 内部的 OpenVPN 客户端；而所有集成都必须连到公网后端这个旧说法，在受支持的私有连接适用的地方就过于绝对了。请选择运行时支持的那一种，然后把通往真实 API 的通路补完：AWS 端点并不认识你的本地资源，也不会继承你笔记本的路由。DNS、后端路由、访问策略和回程流量都必须遵从你选定的架构。半成品的私有通路失败起来，样子和认证问题一模一样。

把私有通路端到端接通

从 API 往外排查，遇到第一个缺口就停下。先确认后端在本地能应答，再确认私有端点能到达它，然后确认具名凭证及其出站连接确实指向那个端点。

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integration

第一条命令证明后端在私有网络内部是健康的，第二条显示域名解析到什么，第三条则从真实的 Salesforce 运行时发起标注调用。第一条返回 200、第三条失败，就能把缺口定位到通路或凭证，而不是服务本身。

接线过程中要把身份范围保持精确。具名凭证本身修不好一个不可达的端点，因为凭证和私有连接是两组相关但职责不同的设置。IP 允许列表只是收窄网络准入，它不是 API 凭证，所以要保留正常的 TLS 校验以及服务自身的认证和轮换流程。如果某个测试只有在你关掉证书校验之后才通过，那你找到的是主机名问题而不是通路问题，证书依然必须匹配。

从运行时验证，然后把回滚记录下来

要从集成运行时、而不是从你自己的机器上，接受一个无害且被允许的请求。记录接收端服务观察到的来源、通过认证的主体、结果，以及一个故意被拒绝、必须失败的请求。

curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/ping

从后端自己的网络再跑一遍同样的两个探测，这样才能把观察到的来源和运行时产生的来源做对比。200 之后跟着 401 或 403 才是你要的形态；两个 200 说明拒绝通路其实并没有生效。

在真正需要之前就把回滚写下来：你改了哪条允许列表条目、哪个具名凭证或哪条出站连接，它归谁所有，以及如何恢复原来的值。然后在工单里写明云端调用方和完整的服务通路，把这个环闭上，免得有人把同一个问题又当成 VPN 问题重新开一遍。

相关文章