Skip to content

Supabase CLI fails with 'Transport error' (antivirus/proxy TLS interception)

Last edited: 8/12/2026

这通常会影响调用管理 API 的 CLI 命令，比如 supabase projects list 和 supabase link：

🌐 This typically affects CLI commands that call the Management API, such as supabase projects list and supabase link:

1
failed to list projects: HttpClientError: Transport error (GET https://api.supabase.com/v1/projects)

为什么会这样 #

🌐 Why this happens

CLI 的 HTTP 客户端会把在收到 HTTP 响应之前发生的任何失败——超时、连接重置、证书被拒——都归类到一个通用的 TransportError 标签下。仅凭消息本身，你无法知属性体发生了哪一种情况，这让单从输出就诊断这个错误变得很困难。

🌐 The CLI's HTTP client buckets any failure that happens before it receives an HTTP response — timeouts, connection resets, certificate rejections — under one generic TransportError label. The message alone doesn't tell you which of these occurred, which makes this error hard to diagnose from the output alone.

一个确认的原因：杀毒软件或企业的 SSL 检查代理会拦截 HTTPS 流量进行扫描。这些软件会安装本地根证书并重新签名连接，这样它们就可以解密、检查并重新加密传输中的流量——这在像 Norton（在“Web 和邮件保护”或“安全网络”等名称下）这样的产品以及企业网络安全代理中都是有记录的功能。CLI 收到的是替换后的证书，而不是 Supabase 的真实证书，因此它会拒绝该证书，显示的就是上面的通用传输错误，而不是证书特定的错误。

🌐 One confirmed cause: antivirus software or corporate SSL-inspecting proxies that intercept HTTPS traffic to scan it. These install a local root certificate and re-sign connections so they can decrypt, inspect, and re-encrypt traffic in transit — a documented feature of products like Norton (under names like "Web and Mail Shield" or "Safe Web") and of enterprise network security proxies. The CLI receives the substituted certificate instead of Supabase's real one and rejects it, surfacing as the generic transport error above rather than a certificate-specific one.

同一台机器上的其他 HTTP 客户端可能表现不同，这其实是一个有用的诊断信号。在一个已确认的案例中（Windows 上的 Norton 360），curl 成功连接，而命令行接口失败，同时 Node 的 fetch() 针对同一个请求显示了更具体的 UNABLE_TO_VERIFY_LEAF_SIGNATURE 错误。

🌐 Other HTTP clients on the same machine can behave differently, which is a useful diagnostic signal. In one confirmed case (Norton 360 on Windows), curl connected successfully while the CLI failed, and Node's fetch() surfaced a more specific UNABLE_TO_VERIFY_LEAF_SIGNATURE error for the same request.

如何诊断 #

🌐 How to diagnose

  • 在同一台机器上比较不同 HTTP 客户端的行为。如果 curl -v https://api.supabase.com 或浏览器能成功，而命令行失败，说明网络路径没问题，差别出在机器本地的某些东西上。
  • 检查 api.supabase.com 提供的证书。在浏览器中，点击地址栏旁的锁图标，然后查看证书的 颁发者 字段。它应该是一个公共 CA（例如 Google Trust Services）。如果显示的是你的杀毒软件供应商或公司的代理 CA，那就是它在拦截连接。
  • 如果你在公司网络上，检查一下你的组织是否使用 SSL 检查代理，以及它的根 CA 是否已经安装并被你的电脑信任。

如何解决 #

🌐 How to resolve

只有在上面的诊断步骤确认是原因后才禁用 HTTPS/TLS 检查——Transport error 也可能是由无关的超时或连接重置引起的，而且禁用你不需要的扫描会不必要地降低你的保护。

🌐 Only disable HTTPS/TLS inspection after the diagnostic step above confirms it's the cause — a Transport error can also come from an unrelated timeout or connection reset, and disabling scanning you don't need reduces your protection unnecessarily.

一旦确认，找出并禁用进行检查的具体功能。这通常是一个独立于一般防火墙或“保护”开关的设置，所以单单关闭主杀毒开关可能不够。在你解决连接问题期间，把它当作临时措施——如果你的软件支持，最好对 api.supabase.com 做一个更具体的主机排除，而不是完全关闭扫描。

🌐 Once confirmed, identify and disable the specific feature doing the inspection. This is often a separate setting from the general firewall or "protection" toggle, so disabling the main antivirus switch alone may not be enough. Treat this as temporary while you resolve connectivity — prefer a narrower host-specific exclusion for api.supabase.com over disabling scanning outright, if your software supports one.

对于 Windows 上的 Norton 360，负责的功能是 Safe Web / 网络与邮件盾，而不是智能防火墙 —— 仅禁用智能防火墙并不会停止拦截。禁用后，确认证书已恢复到预期的颁发者，然后再重试。

🌐 For Norton 360 on Windows, the responsible feature is Safe Web / Web & Mail Shield, not Smart Firewall — disabling Smart Firewall alone does not stop the interception. After disabling it, confirm the certificate reverts to the expected issuer before retrying.

如果你在企业的 SSL 检查代理后面，这通常由你的 IT/安全团队管理，而不是你可以在本地更改的——如果需要，他们可以在代理端为 api.supabase.com 添加一个排除。

🌐 If you're behind a corporate SSL-inspecting proxy, this is managed by your IT/security team rather than something you can change locally — they can add an exclusion for api.supabase.com on the proxy side if needed.