Tunnel

探索 Cloudflare Tunnel 的常见问题和解决方案。

如果在安装远程管理隧道时看到此错误，请确保此机器上没有其他 cloudflared 实例以服务形式运行。任何给定机器上只能有一个 cloudflared 实例以服务形式运行。请改为向您现有的隧道添加额外路由。或者，您可以运行 sudo cloudflared service uninstall 来卸载 cloudflared。

如果无法保存隧道的公共主机名，请选择其他主机名或删除现有 DNS 记录。从 Cloudflare 仪表板 ↗查看您域名的 DNS 记录。

如果在运行隧道时遇到以下错误，请仔细检查您的 config.yml 文件，并确保 credentials-file 指向正确的位置。您可能需要将 /root/ 更改为您的主目录。

cloudflared tunnel run

2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d
Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file

要开始使用 Cloudflare Tunnel，Cloudflare 账户中的超级管理员必须首先通过 cloudflared login 登录。客户端将启动浏览器窗口，提示用户在其 Cloudflare 账户中选择一个主机名。选择后，Cloudflare 会生成一个由三个部分组成的证书：

• 该主机名的源证书公钥
• 该域的源证书私钥
• Cloudflare Tunnel 专用的令牌

这三个部分被捆绑成一个 PEM 文件，在登录流程中只下载一次。主机证书对根域及其下一级子域有效。Cloudflare 使用该证书文件对 cloudflared 进行身份验证，以便在 Cloudflare 中为您的域创建 DNS 记录。

第三部分（令牌）由所选域的区域 ID 和首次使用登录命令进行身份验证的用户的 API 令牌组成。当用户权限发生变化时（例如，该用户从账户中移除或成为另一个账户的管理员），Cloudflare 会滚动该用户的 API 密钥。但是，通过 cloudflared 下载的证书文件保留旧的 API 密钥，可能导致身份验证失败。用户需要再次通过 cloudflared 登录以重新生成证书。或者，管理员可以创建专用的服务用户进行身份验证。

这意味着源站使用了 cloudflared 不信任的证书。例如，如果您的服务器与 Cloudflare 之间的代理中使用了 SSL/TLS 检测，可能会出现此错误。解决方法：

• 将证书添加到系统证书池。
• 使用 --origin-ca-pool 标志并指定证书路径。
• 使用 --no-tls-verify 标志停止 cloudflared 检查证书的信任链。

1033 错误表示您的隧道未连接到 Cloudflare 网络，原因是 Cloudflare 网络无法找到健康的 cloudflared 实例来接收流量。

首先，通过转到 Networking（网络） > Tunnels（隧道） 或运行 cloudflared tunnel list，检查您的隧道在 Cloudflare 仪表板 ↗中是否显示为 Active。如果隧道不是 Active 状态，请根据以下隧道状态检查并采取必要措施：

有关更多信息，请参阅 Cloudflare 1xxx 错误综合列表。

隧道路由上出现带有 Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared 的 502 Bad Gateway 错误，表示隧道本身已连接到 Cloudflare 网络，但 cloudflared 无法访问您的入站规则中定义的源服务。与错误 1033（表示隧道未连接到 Cloudflare）不同，502 错误表明问题出在 cloudflared 和您的本地服务之间。

要找出具体原因，请查看您的隧道日志中的 error 级别消息。常见原因包括：

如果源服务已停止或从未启动，cloudflared 日志将显示类似以下的错误：

error="dial tcp [::1]:8080: connect: connection refused"

要解决此问题，请验证服务是否正在运行并在预期端口上监听：

curl -v http://localhost:8080

如果服务未运行，请启动或重启它。您可以通过运行 ss -tlnp | grep <PORT>（Linux）或 lsof -iTCP -sTCP:LISTEN -nP | grep <PORT>（macOS）来确认服务是否在监听。

如果源站期望 HTTPS 但隧道路由指定了 http://，反之亦然，cloudflared 日志将显示类似以下的错误：

error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\""

要解决此问题，请将隧道路由中的服务 URL 更新为与源站期望的协议匹配。例如，将 http://localhost:8080 更改为 https://localhost:8080。如果您使用的是本地管理的隧道，请更新配置文件中的入站规则。

如果隧道路由中的端口与您的服务正在监听的端口不匹配，cloudflared 将为该端口记录 connection refused 错误。请仔细检查您的入站规则中的服务 URL，并与您的应用程序绑定的端口进行比较。

如果源站提供了 cloudflared 无法验证的 TLS 证书，日志将显示类似以下的错误：

error="x509: certificate is valid for example.com, not localhost"

当源站使用自签名证书或 SSL/TLS 检测代理位于 cloudflared 和源站之间时，通常会发生这种情况。

要解决此问题，请使用以下方法之一：

• 将originServerName设置为您隧道路由中源站证书上的主机名。如果您使用的是本地管理的隧道，以下是配置文件示例：

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        originServerName: app.example.com

• 使用caPool提供 CA 证书：

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        caPool: /path/to/ca-cert.pem

• 作为最后手段，使用noTLSVerify禁用 TLS 验证。不建议在生产环境中使用此方法。

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        noTLSVerify: true

当 cloudflared 无法识别您的源站提供的 SSL/TLS 证书时，会发生此错误。要解决此问题，请将源服务器名称参数设置为您源站证书上的主机名。以下是本地管理的隧道配置示例：

ingress:
  - hostname: test.example.com
    service: https://localhost:443
    originRequest:
      originServerName: test.example.com

这意味着您的 cloudflared access 客户端无法访问您的 cloudflared tunnel 源站。要诊断此问题，请查看 cloudflared tunnel 日志。常见根本原因是 cloudflared tunnel 无法代理到您的源站（例如，因为入站配置错误、源站宕机或 cloudflared tunnel 无法验证源站 HTTPS 证书）。如果 cloudflared tunnel 没有日志，则表示 Cloudflare 网络无法将 WebSocket 流量路由到它。

此错误有以下几种可能的根本原因：

• 您的 cloudflared tunnel 未运行或未连接到 Cloudflare 网络。
• WebSocket 未启用。
• 您的 Cloudflare 账户已启用通用 SSL，但您的 SSL/TLS 加密模式设置为 Off (Not Secure)（关闭（不安全））。要解决此问题，请在 Cloudflare 仪表板中转到 SSL/TLS > Overview（概览），将 SSL/TLS 加密模式设置为 Flexible（灵活）、Full（完全） 或 Full (strict)（完全（严格））。
• 您的请求被 Super Bot Fight Mode 阻止。要解决此问题，请确保在机器人对抗模式设置中将明确的自动化设置为_允许_。
• 您的 SSH 或 RDP Access 应用程序已启用绑定 Cookie。要禁用此 Cookie，请转到 Access controls（访问控制） > Applications（应用程序） 并编辑应用程序设置。
• 一个或多个 Workers 路由与隧道主机名重叠，而 Workers 未正确处理流量。要解决此问题，请通过不定义包含隧道主机名的路由来将您的隧道排除在 Worker 路由之外，或者更新您的 Worker 以仅处理特定路径并将所有其他请求转发到源站（例如，使用 return fetch(req)）。

如果 cloudflared 返回错误 error="remote error: tls: handshake failure"，请检查相关主机名是否有 SSL 证书覆盖。如果使用多级子域名，可能需要高级证书，因为通用 SSL 不覆盖超过一级的子域名。这可能在浏览器中显示为 ERR_SSL_VERSION_OR_CIPHER_MISMATCH。

如果您的Cloudflare Tunnel 日志返回 socket: too many open files 错误，表示 cloudflared 已耗尽您机器上的打开文件限制。最大打开文件数（或文件描述符数）是操作系统设置，用于确定一个进程允许打开多少个文件。要提高打开文件限制，您需要在运行 cloudflared 的机器上配置 ulimit 设置。

此缓冲区大小增加由 cloudflared ↗ 利用的 quic-go 库 ↗报告。您可以在 quic-go 仓库 ↗中了解有关此日志消息的更多信息。此日志消息通常不会产生影响，在故障排查时可以安全忽略。但是，如果您在高带宽的特殊环境中部署了 cloudflared，则可以手动覆盖缓冲区大小以进行测试。

要在 Linux 上设置最大接收缓冲区大小：

1. 在 /etc/sysctl.d/ 下创建一个新文件：

   sudo vi 98-core-rmem-max.conf

2. 在文件中定义所需的缓冲区大小：

   net.core.rmem_max=2500000

3. 重启运行 cloudflared 的主机。

4. 要验证这些更改是否已生效，请使用 grep 命令：

   sudo sysctl -a | grep net.core.rmem_max

   net.core.rmem_max = 2500000

除非源服务器包含 Content-Type: text/event-stream 响应头，否则通过 Cloudflare Tunnel 代理的流量默认会被缓冲。此响应头告知 cloudflared 在数据到达时进行流式传输，而不是缓冲整个响应。

有关更多信息，请参阅完整的 Tunnel 故障排除指南。