1. 项目概述与核心价值

最近在折腾一个内部工具，叫 Hermes Agent，这玩意儿本质上是一个智能体管理面板，能帮你集中管理、调度和监控各种 AI 智能体。功能挺酷，但问题来了：它的官方 Dashboard 默认是跑在本地或者内网的。对于我这种经常需要在外头临时查看状态、或者想给团队成员开个安全访问权限的人来说，每次都得先连回公司内网，麻烦不说，安全性也是个隐患——总不能为了图方便就把内网端口直接暴露在公网上吧。

这时候，Cloudflare Tunnel 就进入了我的视线。它不是什么新鲜玩意儿，但在解决“安全地将本地服务暴露到公网”这个老大难问题上，确实是一把好手。简单来说，它能在你的本地服务和 Cloudflare 的边缘网络之间，建立一条加密的、出站连接的隧道。这意味着，你的服务本身不需要有公网 IP，也不需要在你自己的防火墙上开任何入站端口，所有的流量都先经过 Cloudflare 的全球网络，再通过这条加密隧道“钻”回你的本地环境。安全性、可控性都大大提升。

所以，这个实践的核心目标就明确了： 在不直接暴露内网端口、不牺牲安全性的前提下，将 Hermes Agent 的 Dashboard 面板安全、稳定地发布到公网，实现随时随地、受控的访问。 整个过程会涉及到 Cloudflare Zero Trust 平台的配置、Tunnel 的创建与运行，以及如何与 Hermes Agent 的服务进行集成。无论你是个人开发者想远程管理自己的 AI 助手集群，还是团队需要共享一个安全的监控入口，这套方案都值得一试。

2. 方案选型：为什么是 Cloudflare Tunnel？

在决定把内部服务弄到公网能访问时，我们通常有几个选择：端口转发（Port Forwarding）、反向代理（如 Nginx + 域名 + SSL）、内网穿透工具（如 frp、ngrok），以及像 Cloudflare Tunnel 这样的零信任网络访问（ZTNA）方案。我最终选择 Tunnel，是基于下面几个核心考量，这也是你在做类似决策时需要想清楚的。

2.1 传统方案的痛点分析

首先，最直接但也最危险的就是在路由器上做端口转发。你把内网某台机器的 8080 端口映射到公网 IP 的 8080 端口。这样做，你的服务就直接暴露在互联网上了，直面各种扫描和攻击。除非你的应用本身有极其强大的认证和防护，否则这无异于“裸奔”。对于 Hermes Agent Dashboard 这种管理界面，风险太高，第一时间就被排除了。

其次，是使用反向代理（比如 Nginx 或 Caddy）配合一个云服务器。你在云服务器上装好 Nginx，配置好域名和 SSL 证书，然后将请求反向代理到你内网机器的 IP 和端口。这比直接端口转发安全一些，因为云服务器本身有防火墙，你可以只开放 80/443 端口。但问题依然存在：你的云服务器需要一个公网 IP，并且你仍然需要在你内网的防火墙上，为云服务器的 IP 开一个“入站”的白名单端口。这本质上还是一种“开门迎客”的模式，只是门卫（云服务器）更专业一些。运维成本（维护云服务器、证书）和潜在的攻击面（云服务器被攻破可能导致内网沦陷）依然不低。

再者，是内网穿透工具，比如 frp。它需要在公网有一台具有固定 IP 的服务器作为“服务端”，在内网机器上运行“客户端”。客户端主动连接到服务端，建立隧道，将内网服务映射出去。这个方案比反向代理更灵活，因为内网机器是主动出站的，不需要在本地防火墙开入站规则。但它的缺点是，你需要自己维护那台公网服务器，同样涉及服务器的安全、网络的稳定性以及域名、SSL 证书的管理。对于追求“省心”和“安全集成度”的场景，它还不够“懒人友好”。

2.2 Cloudflare Tunnel 的核心优势

Cloudflare Tunnel（以前叫 Argo Tunnel）的思路完全不同，它属于“零信任网络访问”的范畴。它的工作模式是“只出不进”：

1. 主动出站，无需公网IP与开放端口 ：你在本地运行一个轻量级的守护进程 cloudflared 。这个进程会主动、持续地连接到 Cloudflare 遍布全球的边缘网络。因为连接是本地发起的，所以你完全不需要在本地路由器或防火墙上配置任何入站端口转发。你的内网对于公网来说，依然是“隐身”的。
2. 流量加密与路由 ：所有从公网用户到你本地服务的流量，都会先到达离用户最近的 Cloudflare 数据中心。然后，Cloudflare 会通过这条已经建立好的、TLS 加密的隧道，将流量安全地传递给你的 cloudflared 进程，再由它转发给本地的 Hermes Agent Dashboard。这个过程中，流量始终在 Cloudflare 的可信网络内或加密隧道中，避免了在公网明文传输的风险。
3. 与 Cloudflare 生态深度集成 ：这是最大的亮点。Tunnel 天然与 Cloudflare 的其他服务无缝结合：
   • Access（零信任访问控制） ：你可以轻松地为你的 Hermes Dashboard 设置访问策略。比如，只允许特定邮箱后缀（公司邮箱）的用户访问，或者要求进行二次验证（2FA）。没有通过 Access 策略验证的用户，连看到登录页面的机会都没有，直接在 Cloudflare 边缘就被拦截了。
   • DNS 与 SSL ：域名解析和 SSL/TLS 证书的签发、续期完全由 Cloudflare 自动管理。你不需要自己申请和更新证书，全程 HTTPS，且证书来自受信任的 CA。
   • DDoS 防护与 WAF ：你的服务自动享受 Cloudflare 的全球分布式网络提供的 DDoS 缓解和可选的 Web 应用防火墙（WAF）保护。恶意流量在到达你的隧道之前就被清洗掉了。

2.3 决策总结与适用场景

基于以上对比，选择 Cloudflare Tunnel 来部署 Hermes Agent Dashboard，核心是看中了它的 “安全省心” 。你不需要管理公网服务器，不需要操心防火墙规则，不需要手动处理 SSL 证书，还能免费获得企业级的访问控制和安全防护。它特别适合以下场景：

• 部署像 Hermes Dashboard、Jenkins、GitLab、各类监控面板（如 Grafana）等需要受控外部访问的内部 Web 服务。
• 个人或小团队，没有专门的运维人员，希望以最小成本获得最高安全性的公网访问方案。
• 需要快速为内部服务添加基于身份的多因素认证（MFA）等高级安全功能。

当然，它也不是万能的。由于流量需要经过 Cloudflare 的网络，对于网络延迟极度敏感（例如实时竞技游戏）或数据合规性要求必须流量不出境的服务，可能需要评估。但对于绝大多数管理类、工具类 Web 服务，包括我们的 Hermes Agent Dashboard，它都是目前综合最优解。

3. 前期准备与环境配置

在动手敲命令之前，我们需要把“舞台”搭好。这部分工作虽然繁琐，但每一步都关系到后续流程能否顺畅。请严格按照步骤操作，我会把容易踩坑的地方重点标出来。

3.1 Cloudflare 账户与域名准备

首先，你得有一个 Cloudflare 账户。如果还没有，去官网注册一个，免费套餐（Free Plan）就完全够用，并且已经包含了 Tunnel 和 Access 的基本功能。

其次，也是 最关键的一步 ，你需要有一个属于自己的域名，并且将其 DNS 托管到 Cloudflare。这意味着，你要在域名注册商那里，将域名的 Nameserver（NS 记录）修改为 Cloudflare 提供的 NS 服务器地址。

注意 ：很多新手卡在这一步。请确保你的域名在 Cloudflare 控制台的 “Websites” 里显示状态是 “Active”，并且 DNS 记录的管理权已在 Cloudflare。如果你只是添加了 A 记录，但 NS 服务器没改过来，Tunnel 将无法正确为你分配 SSL 证书和路由流量。

假设你拥有的域名是 yourdomain.com ，并且已经成功托管在 Cloudflare 上。

3.2 安装与认证 cloudflared

cloudflared 是 Cloudflare Tunnel 的客户端守护进程，我们需要在运行 Hermes Agent Dashboard 的机器上安装它。它支持 Windows、macOS、Linux 等多种系统。

以最常见的 Linux 服务器（如 Ubuntu 22.04）为例，安装步骤如下：

# 下载最新版本的 cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb

# 安装（对于 Debian/Ubuntu 系统）
sudo dpkg -i cloudflared-linux-amd64.deb

# 验证安装
cloudflared --version

安装完成后，我们需要让 cloudflared 知道它应该为哪个 Cloudflare 账户工作。这就需要进行认证：

cloudflared tunnel login

执行这个命令后，它会打印出一个 URL。用浏览器打开这个 URL，登录你的 Cloudflare 账户，并授权给 cloudflared 。授权成功后，它会自动在你的机器上生成一个证书文件（通常位于 ~/.cloudflared/cert.pem ）。这个证书用于 cloudflared 后续与 Cloudflare 通信时的身份验证。

3.3 Hermes Agent Dashboard 本地运行确认

在配置 Tunnel 之前，你必须确保 Hermes Agent Dashboard 在本地已经可以正常访问。根据 Hermes Agent 的安装方式（Docker、直接二进制运行等），它通常会监听一个本地端口。

假设你通过 Docker 运行 Hermes Agent，其 Dashboard 服务映射到了本地的 8080 端口。那么，你应该能在服务器上通过 curl http://localhost:8080 或者浏览器访问 http://<服务器内网IP>:8080 来看到 Dashboard 的登录或欢迎页面。

请务必记录下这个 本地访问地址和端口 ，例如 http://localhost:8080 或 http://192.168.1.100:8080 。这是后续配置 Tunnel 时需要的核心信息。

实操心得 ：建议在本地先完整测试一遍 Hermes Agent 的功能，确保它本身运行无误。因为 Tunnel 只负责网络连通性，如果服务本身有问题，暴露到公网后问题依旧，排查起来会更复杂。

4. 创建并配置 Cloudflare Tunnel

环境准备好后，我们就可以开始创建隧道了。隧道是连接你本地服务和 Cloudflare 网络的逻辑通道。

4.1 创建隧道

在服务器上，使用以下命令创建一个新的隧道，并给它起个名字，比如 hermes-dashboard-tunnel ：

cloudflared tunnel create hermes-dashboard-tunnel

命令执行成功后，你会看到类似下面的输出：

Tunnel credentials written to /home/username/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json.
Created tunnel hermes-dashboard-tunnel with id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

这里有两个关键信息：

1. 隧道ID ：一串 UUID，是隧道的唯一标识。
2. 凭证文件路径 ：一个 JSON 文件，里面包含了隧道连接所需的密钥。 务必保管好这个文件 ，它等同于隧道的“密码”。Cloudflare 建议你将其备份到安全的地方。

4.2 配置隧道路由（Config File）

接下来，我们需要告诉隧道，它需要把哪些公网流量转发到本地的哪个服务。这是通过一个 YAML 格式的配置文件完成的。

首先，生成一个默认的配置文件模板：

cloudflared tunnel config generate

这通常会在 ~/.cloudflared/config.yml 生成一个文件。但我们更推荐为每个隧道创建独立的配置文件，管理起来更清晰。

在 ~/.cloudflared/ 目录下，创建一个新的配置文件，例如 hermes-config.yml ：

tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # 替换为你的隧道ID
credentials-file: /home/username/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json # 替换为你的凭证文件路径

ingress:
  - hostname: hermes.yourdomain.com # 你希望使用的子域名
    service: http://localhost:8080 # Hermes Dashboard 的本地访问地址
  - service: http_status:404 # 默认规则，匹配不上上述规则的流量返回404

配置详解：

• tunnel 和 credentials-file ：指向你刚创建的隧道。
• ingress ：定义入站流量规则，是一个列表。
• 第一条规则：当访问的域名是 hermes.yourdomain.com 时，将流量转发给本地的 http://localhost:8080 服务。
• 第二条规则： service: http_status:404 这是一个 非常重要的安全规则 。它作为默认规则，会捕获所有未被前面规则匹配的流量，并返回 404 错误。这可以防止有人通过猜测其他子域名来访问你的隧道。

4.3 创建 DNS 记录

现在，我们需要在 Cloudflare 的 DNS 设置中，为你配置的子域名（ hermes.yourdomain.com ）创建一条记录，将其指向你的隧道。

你可以通过 Cloudflare 仪表板手动操作，但更推荐使用 cloudflared 命令自动完成，这样能确保记录类型正确（是 CNAME 到特定的 Tunnel 域名）：

cloudflared tunnel route dns hermes-dashboard-tunnel hermes.yourdomain.com

将 hermes-dashboard-tunnel 替换为你的隧道名称， hermes.yourdomain.com 替换为你的子域名。

执行成功后，去 Cloudflare 控制台的 DNS 页面查看，应该会自动生成一条类型为 CNAME ，名称是 hermes ，目标值类似 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.cfargotunnel.com 的记录。这条记录的意思是将 hermes.yourdomain.com 的解析指向 Cloudflare 的隧道网络。

5. 运行隧道与验证连通性

配置完成后，是时候启动隧道，让一切运转起来了。

5.1 以非托管模式运行隧道

对于长期运行的服务，我们通常以后台服务（如 systemd）的方式运行 cloudflared 。但在测试阶段，可以先在前台运行，方便查看日志：

cloudflared tunnel --config ~/.cloudflared/hermes-config.yml run hermes-dashboard-tunnel

如果一切正常，你会看到 cloudflared 连接成功的日志，类似：

INF Connection xxxxxxxx registered connIndex=0 location=XXX
INF Connected to xxxxxxxx

5.2 配置为系统服务（以 systemd 为例）

测试无误后，将其配置为系统服务，实现开机自启和自动守护：

# 安装 cloudflared 为系统服务
sudo cloudflared service install

# 将我们的隧道配置文件设为默认配置（覆盖默认的config.yml）
sudo cp ~/.cloudflared/hermes-config.yml /etc/cloudflared/config.yml

# 确保凭证文件对服务账户可读（重要！）
sudo cp ~/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json /etc/cloudflared/
# 修改配置文件中的凭证文件路径为 /etc/cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

# 重启 cloudflared 服务
sudo systemctl restart cloudflared

# 查看服务状态和日志
sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f

5.3 公网访问验证

隧道运行起来后，打开你的浏览器，访问 https://hermes.yourdomain.com 。你应该能看到 Hermes Agent Dashboard 的页面了。

验证要点：

1. HTTPS ：确认地址栏是 https:// 开头，并且证书是有效的（由 Cloudflare 签发）。这是 Tunnel 自动完成的。
2. 连通性 ：页面能正常加载，功能可用。
3. 延迟 ：由于流量需要绕行 Cloudflare 网络，可能会比直接内网访问稍有延迟，但在可接受范围内。

如果访问失败，请按顺序排查：

1. 检查 cloudflared 服务是否正在运行 ( sudo systemctl status cloudflared )。
2. 检查 cloudflared 日志是否有错误 ( sudo journalctl -u cloudflared -n 50 )。
3. 在 Cloudflare 控制台检查 DNS 记录是否生效（可以 ping 一下你的子域名，看是否解析到 cfargotunnel.com 的地址）。
4. 确认本地 Hermes Dashboard 服务 ( http://localhost:8080 ) 本身是否正常。

6. 增强安全：集成 Cloudflare Access 实现零信任访问

到目前为止，你的 Dashboard 已经可以通过公网访问了，并且流量是加密的。但这还不够，因为任何人只要知道了这个网址，都能访问。接下来，我们将使用 Cloudflare Access 为它加上一道“门禁”，实现零信任访问。

6.1 什么是 Cloudflare Access？

简单理解，Access 是一个反向代理前的身份认证和授权层。它允许你基于一系列规则（如用户邮箱、IP 地址、国家、设备状态等）来控制谁可以访问你的应用。用户访问时，会先被重定向到 Cloudflare 的认证页面，只有满足策略的用户才能看到后面的实际应用。

6.2 为 Hermes Dashboard 创建 Access 策略

1. 登录 Cloudflare Zero Trust 面板 ：在 Cloudflare 仪表板，找到 “Zero Trust” 应用并进入。
2. 创建应用 ：导航到 “Access” -> “Applications”，点击 “Add an application”。
3. 选择应用类型 ：选择 “Self-hosted”。
4. 配置应用 ：
   • Application name : 填写一个易识别的名字，如 “Hermes Production Dashboard”。
   • Session Duration : 设置会话有效期，例如 24 小时。
   • Application domain : 这里填写我们之前配置的子域名 hermes.yourdomain.com 。 这是关键 ，Access 将保护这个域名。
5. 配置策略（Policy） ：这是 Access 的核心。点击 “Add a policy”。
   • Policy name : 例如 “Team Members Only”。
   • Action : 选择 “Allow”。
   • Configure rules : 添加规则。一个常见的规则是 “Email”，操作符选择 “matches regex”，值填入你团队邮箱的后缀，例如 .*@yourcompany\.com$ 。这样，只有使用公司邮箱登录的用户才能通过。
   • 你还可以添加更多规则，比如 “Require 2FA”（要求二次验证）、“Country”（限制国家）等，组合使用。
6. 完成创建 ：保存应用和策略。

6.3 验证 Access 保护

创建完成后，再次访问 https://hermes.yourdomain.com 。这次，你不会直接看到 Dashboard，而是会被重定向到一个 Cloudflare 的登录页面。

你需要使用符合策略的邮箱（如公司邮箱）登录。登录成功后，才会被允许访问背后的 Hermes Dashboard。对于未授权的用户，他们会看到拒绝访问的页面。

注意事项 ：Access 的认证发生在 Cloudflare 边缘网络。这意味着，非法访问请求在到达你的 Tunnel 和本地服务器之前就被拦截了，极大地减少了本地服务的暴露面和攻击压力。同时，Hermes Dashboard 本身可能也有登录认证，这就形成了两道安全防线（Access + 应用自身登录），安全性更高。

7. 高级配置与优化

基础功能跑通后，我们可以根据实际需求进行一些优化和高级配置，让服务更稳定、更易用。

7.1 配置高可用与负载均衡

如果你的 Hermes Agent 部署在多台机器上，或者你希望 Tunnel 连接更稳定，可以配置高可用。

• 多实例 Tunnel ：你可以在多台服务器上安装 cloudflared ，使用 相同的隧道凭证文件（JSON） 和配置文件，然后同时运行。Cloudflare 会自动在这些实例间进行负载均衡和故障转移。
• 配置方法 ：只需将之前生成的 tunnel credentials JSON 文件和 config.yml 复制到另一台服务器，按照同样的步骤安装 cloudflared 并运行即可。确保它们指向同一个隧道 ID。

7.2 性能调优与监控

• 连接数 ：在 config.yml 中，可以通过 originRequest 下的参数进行调优，例如 keepAliveConnections （保持连接数）、 keepAliveTimeout （保持连接超时）等，以适应高并发场景。对于 Hermes Dashboard 这类管理面板，通常默认配置即可。
• 日志与监控 ： cloudflared 的日志级别可以通过环境变量 TUNNEL_LOGLEVEL 控制（如 info , debug ）。在生产环境，建议设置为 info 以减少日志量。你可以使用 journalctl 或将日志导出到文件/外部监控系统（如 Loki, ELK）进行集中分析。
• 资源占用 ： cloudflared 本身非常轻量，内存和 CPU 占用很低。但需要关注其网络连接状态。

7.3 与 Hermes Agent 的深度集成考量

Hermes Agent 可能有一些特定的需求，需要在 Tunnel 配置中考虑：

• WebSocket 支持 ：如果 Dashboard 使用了 WebSocket 进行实时通信（例如显示 Agent 的实时状态流），Tunnel 默认是支持的，无需特殊配置。
• 长连接与超时 ：如果 Dashboard 有长时间轮询或 Server-Sent Events (SSE)，确保 cloudflared 和 Cloudflare 网络的超时设置足够长。可以在 config.yml 的 originRequest 部分设置 connectTimeout 、 tlsTimeout 、 tcpKeepAlive 等参数。
• 自定义 HTTP 头 ：有时需要向 Hermes 服务传递一些特定的头信息。可以在 config.yml 的 originRequest 部分使用 httpHostHeader 或 originServerName 来修改 Host 头，或者通过 proxyType 来调整代理行为。

一个更完整的 ingress 规则配置示例，考虑了更多细节：

ingress:
  - hostname: hermes.yourdomain.com
    service: http://localhost:8080
    originRequest:
      connectTimeout: 30s
      httpHostHeader: hermes.yourdomain.com
      noTLSVerify: false # 如果你的本地服务使用自签名证书，可能需要设为 true，但生产环境不推荐
  - service: http_status:404

8. 常见问题排查与解决方案实录

在实际部署和运维过程中，你几乎一定会遇到一些问题。下面是我踩过的一些坑以及解决方法，希望能帮你快速排雷。

8.1 隧道连接失败或频繁断开

• 症状 ： cloudflared 日志中出现 connection failed , failed to connect to edge 等错误，或者隧道状态不稳定。
• 排查步骤 ：
  1. 网络连通性 ：首先确认服务器本身能正常访问互联网，特别是能连接到 Cloudflare 的网络（如 cloudflare.com ）。可以尝试 curl -v https://cloudflare.com 。
  2. 认证过期 ：检查 ~/.cloudflared/cert.pem 证书是否过期。可以尝试重新运行 cloudflared tunnel login 获取新证书。
  3. 凭证文件权限 ：如果配置为系统服务，确保 /etc/cloudflared/ 目录下的凭证 JSON 文件对 cloudflared 服务运行用户（通常是 cloudflared ）有读取权限。 sudo chown cloudflared:cloudflared /etc/cloudflared/xxx.json 。
  4. 防火墙/安全组 ：虽然 Tunnel 是出站连接，但请确认服务器本地防火墙或云服务商的安全组没有阻止 cloudflared 的出站连接（尤其是到 443、7844 等端口的连接）。
  5. DNS 解析 ：确保服务器使用的 DNS 能正常解析 Cloudflare 的相关域名。可以尝试在 config.yml 中显式指定 dns 服务器，如 dns: { upstreams: [“1.1.1.1”, “8.8.8.8”] } 。

8.2 公网访问返回 5xx 错误（如 502, 503）

• 症状 ：能打开页面，但显示 Cloudflare 5xx 错误页面。
• 排查步骤 ：
  1. 本地服务状态 ：这是最常见的原因。立即检查 Hermes Dashboard 本地服务是否还在运行： curl http://localhost:8080 。如果本地都访问不了，问题出在 Hermes 本身。
  2. 配置错误 ：检查 config.yml 中的 service 地址和端口是否正确。确保 cloudflared 运行的用户有权访问该本地端口。
  3. 资源不足 ：检查本地服务器资源（CPU、内存）是否耗尽，导致 Hermes 或 cloudflared 进程崩溃。
  4. 查看详细日志 ：运行 cloudflared tunnel --config /path/to/config.yml run --loglevel debug <tunnel-name> 开启调试日志，查看连接和转发过程中的具体错误信息。

8.3 Access 认证后无法访问应用（无限重定向或空白页）

• 症状 ：通过了 Access 登录，但页面白屏、一直加载或循环重定向。
• 排查步骤 ：
  1. Cookie/缓存 ：首先清除浏览器 Cookie 和缓存，尝试无痕模式访问。这是解决此类问题最快的方法。
  2. 应用会话冲突 ：Hermes Dashboard 自身的登录会话可能与 Access 的认证 Cookie 冲突。尝试在 Access 策略的 “Settings” 中，启用 “Browser Rendering” 或调整 “Session Duration”。有时，在 config.yml 的 originRequest 中设置 noTLSVerify: true （仅用于测试）可以排除证书问题。
  3. CORS 问题 ：如果 Dashboard 前端大量使用 AJAX 请求，且配置了严格的 CORS（跨域资源共享）策略，可能会因为域名变化（经过 Access 代理）而导致请求被浏览器阻止。这需要在 Hermes Dashboard 的后端服务中正确配置 CORS 响应头，允许来自你域名的请求。

8.4 DNS 解析问题或 SSL 证书错误

• 症状 ：浏览器提示“您的连接不是专用连接”、“SSL 证书错误”或“无法找到该网站”。
• 排查步骤 ：
  1. DNS 传播 ：确认 DNS 记录（CNAME）已正确创建并生效。可以使用 dig hermes.yourdomain.com 或在线 DNS 查询工具，看是否解析到 xxx.cfargotunnel.com 。
  2. 等待 SSL 证书签发 ：在首次创建 Tunnel 并设置 DNS 后，Cloudflare 需要几分钟到几十分钟来为你的域名自动签发 SSL 证书。在此期间访问会得到证书错误。请耐心等待。
  3. 混合内容警告 ：确保你的 Hermes Dashboard 页面内加载的所有资源（CSS, JS, 图片）都使用 HTTPS 链接，否则浏览器会因“混合内容”而报警或阻止。

8.5 性能问题（访问速度慢）

• 症状 ：页面加载缓慢，操作响应延迟高。
• 排查步骤 ：
  1. 本地服务性能 ：首先排除 Hermes Dashboard 本身性能问题。直接在内网访问，看是否同样慢。
  2. Cloudflare 数据中心 ：Cloudflare 会自动将用户路由到最近的 PoP（接入点）。你可以尝试从不同地区访问，看是否是特定区域网络问题。
  3. 隧道连接质量 ： cloudflared 与 Cloudflare 边缘之间的连接质量。可以尝试在 config.yml 中为隧道指定不同的 region （地区），或者启用 protocol: quic （如果支持）来优化连接。
  4. 优化 Hermes Dashboard ：对 Dashboard 的前端资源（如图片、JS）进行压缩、合并，启用浏览器缓存等，是提升感知速度的有效手段。

把 Hermes Agent Dashboard 通过 Cloudflare Tunnel 安全地部署到公网，整个过程像搭积木，每一步都有明确的依赖。核心思路就是用一条加密的“单向隧道”代替危险的“开门迎客”，再用 Access 这道智能门禁来精细化控制访客。这套组合拳下来，不仅安全性远超传统方案，后期的运维负担也轻得多——SSL 证书、DDoS 防护这些头疼事都交给了 Cloudflare。

我个人在多个项目里都用这个模式部署内部工具，最大的体会就是“省心”。一旦跑通，几乎不需要维护。唯一需要定期关注的就是 cloudflared 的版本更新，以及 Access 策略里的成员名单是否需要调整。如果 Hermes Agent 未来升级，或者你需要部署其他类似的服务，这套流程完全可以复用，算是一次投入，长期受益。最后一个小建议，把所有用到的域名、隧道 ID、配置文件路径都记录在一个文档里，时间久了或者服务器迁移时，你会感谢自己这个习惯的。