通过 VPN 登录 Salesforce CLI：CLI、浏览器与 API 主机

Salesforce CLI 的登录失败通常被当成一个问题上报，但实际上往往是三个问题。CLI 进程在某台机器上运行，完成网页流程的浏览器在另一台机器上运行，之后的 API 调用又在某处运行，而这三处并不必然共用同一条路由、同一个解析器或同一份允许列表。把三者逐一对比，是判断隧道究竟挡住了哪一环的最快办法。登录输出里没有任何一行会指明三者中究竟是哪一个失败。

三台主机，一个登录故事

网页登录流程把身份验证这一步交给浏览器，而浏览器常常位于你的笔记本上，CLI 则位于远程开发主机或容器中。笔记本上有 VPN 客户端，远程主机上有平台团队给它的配置，两套安排都不会自动覆盖对方。状态栏里的 VPN 图标，对于一台从未运行过客户端的主机毫无意义。

登录之后，CLI 会从进程所在的位置自行发起 API 请求。这些请求需要 DNS、路由、TLS 信任以及 org 侧的客户端授权，这是四项彼此独立的检查，每一项都可能单独失败。一个登录得很顺利的浏览器，对上述任何一项都不能说明什么。

把两半放在同一条时间线上，但要分开打分。这样一张工单就能说清是哪一半坏了，而不必变成关于归属的争论。

org 条目要向 org 索取，不要凭记忆

网页流程会取一个实例 URL，并把结果存到某个别名之下，这两个值都应该来自 org 所有者，而不是同事的终端历史记录。从旧工单里抄来的沙箱主机，是登录认证到错误 org、随后每条查询都失败的一个常见原因。

使用已安装插件文档所写的形式，配上你自己获批准的主机和别名。该文档是那些在 sfdx 与当前 CLI 之间发生变化了的参数的参考。

sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uat

上面的主机名和别名只是示例，不是你应该照抄的默认值。 按常规完成浏览器身份验证和 MFA 步骤，不要用脚本绕过它们，也绝不要把密码、会话标识或验证器种子写进 shell 命令来跳过提示。

缓存下来的授权能证明什么

出现在本地授权列表里的别名，证明这台机器上曾经成功登录过一次。该列表是从本地存储读出的，并不会联系 org 去确认令牌是否仍然有效，所以一条看起来健康的记录和一次被拒绝的 API 调用可以同时成立。把缓存当作对过去的记录，而不是对连通性的实时测试。缓存检查能回答一个支持问题，但它永远不会终结一次连通性排查。

同样的区分也适用于浏览器会话。标签页仍然显示 org，并不代表 CLI 保存的令牌符合当前策略，因为令牌寿命、IP 限制和客户端应用规则都在 API 边界上强制执行。

删除本地记录之前先读一遍，因为别名和 org 主机是支持人员一定会问的两项事实。删除别名是可逆的，但在事故进行中删掉错的那一个，只会多出第二个问题。

API 请求究竟在哪里被拒绝

把一个请求从头到尾跟一遍，记下是哪个组件在应答。TLS 失败、403 和超时指向三种不同的问题，而三者之中只有超时会把隧道列为首要嫌疑。先读错误类别再读错误消息，可以省下大量猜测。在重跑任何东西之前，先把类别写下来。

源地址限制正是那种「登录能用、查询不能用」的情形，因为浏览器流程和 API 调用可能从不同地址出去。用更宽的允许列表来修，是 org 所有者的决定而不是图省事，而且应当覆盖该主机的最小范围。

记下失败的命令、别名、执行主机和时间戳，别把令牌写进要贴到工单里的任何内容。那段四行摘要，才是 org 所有者排查自己一侧时需要的。

从真正会使用它的主机上验证流程

在将要执行工作负载的机器上测试。在你笔记本上验证通过的登录，对另一网络区域的构建代理说明不了任何事，而这个差异恰恰是你要找的。

检查时使用一次无害且已获授权的读取，如果失败，保留第一个错误。

sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"

当登录成功而查询失败时，剩下的候选是 DNS、路由、TLS 拦截和 org 侧的客户端策略，每一项都有自己的负责人。当登录本身失败时，浏览器和 CLI 很可能不在同一台主机上，修复属于两者之间的安排，而不属于隧道。自动化还要多一条规则：无人值守的任务需要经批准的、基于证书的登录，因为把缓存下来的交互式会话复制到 worker 上，不是一种身份设计。