cloudflaresecurityai-agent

我是怎么让手机也能安全访问 Hermes WebUI 的

记录一次把 VPS 上只监听本机的 Hermes WebUI 接入 Cloudflare Tunnel 和 Cloudflare Access 的过程,让手机、电脑和平板都能通过受保护的 HTTPS 域名访问。

Sylwair11 分钟

Hermes WebUI 安全访问封面

我在自己的 VPS 上部署了 Hermes Agent,也部署了一个 Hermes WebUI,用来管理和操作这个 Agent。

一开始,我访问 WebUI 的方式很简单:在本地电脑开一条 SSH 本地端口转发,然后在浏览器里打开本机地址。

ssh -N -L 本地端口:127.0.0.1:WebUI端口 用户名@服务器IP

这个办法能用,适合临时调试。

问题也很快出现了。

只要 SSH 连接断了,页面就打不开。换一台电脑,又要重新来一遍。最麻烦的是,手机根本不能直接用这个地址访问。

因为手机上的 127.0.0.1 指的是手机自己。

所以这件事最后要解决的是一个更完整的访问入口问题:

怎么把 VPS 上只在本机开放的 Hermes WebUI,
变成手机、电脑、平板都能访问,
同时又不裸露在公网的 HTTPS 入口?

我最后用的方案是:

Cloudflare Tunnel + Cloudflare Access

前者负责把 VPS 上的本地 Web 服务接到自定义域名,后者负责在进入 WebUI 前做身份验证。

我使用的 WebUI 仓库是:

https://github.com/nesquena/hermes-webui.git

为什么 SSH 转发不适合长期使用

SSH 本地端口转发很适合临时访问服务器上的内部服务。

比如你要看一个后台面板,临时调一个管理页面,或者只想在当前电脑上访问一下服务器里的本地服务,它很方便。

但如果这个 WebUI 是你每天都要用的入口,它就有点别扭。

你必须一直开着终端。你必须保持 SSH 连接不断。你只能在执行命令的那台电脑上访问。

手机访问不了,是因为很多人第一次会误解 127.0.0.1

127.0.0.1 永远代表当前设备自己。

在 VPS 上访问 127.0.0.1,访问的是 VPS 自己
在电脑上访问 127.0.0.1,访问的是电脑自己
在手机上访问 127.0.0.1,访问的是手机自己

SSH 本地转发是在电脑上开了一个本地入口,再把流量转到 VPS。手机没有接入这条本地链路,自然访问不到。

如果想让手机也能访问,就需要一个真正的 HTTPS 入口。

为什么不能直接开放 WebUI 端口

这里还有一个更重要的前提:Hermes WebUI 不能直接裸露到公网。

它属于高权限操作入口。它背后连接的是 AI Agent,可以管理任务、读写文件、调用工具,权限比普通网站高得多。

如果只是为了方便访问,就把 WebUI 端口直接开放到公网,风险会很高。

更稳妥的边界是:

WebUI 继续只监听 VPS 本机地址
公网访问交给 Cloudflare Tunnel
访问身份交给 Cloudflare Access
WebUI 自身如果有密码,继续作为第二层保护

这也是这次方案的核心。

最终访问链路

配置完成后,我访问 WebUI 的链路变成了这样:

手机或电脑浏览器
  ↓
自定义 HTTPS 域名
  ↓
Cloudflare Access 邮箱验证
  ↓
Cloudflare Tunnel
  ↓
VPS 上的 Hermes WebUI

第一次访问域名时,会先看到 Cloudflare Access 的验证页。只有通过指定邮箱验证后,才能继续进入 Hermes WebUI。

Cloudflare Access 验证页

这样即使别人知道了域名,也不能直接进入 WebUI。

这件事具体做了哪些层

如果把命令细节先收起来,这件事其实就是几层。

第一层,确认 Hermes WebUI 在 VPS 本地能打开。

也就是说,先在 VPS 上确认本地地址可访问。只要这一步没通过,就不要急着配置 Tunnel。公网入口解决不了本地服务本身不可用的问题。

第二层,安装并登录 cloudflared。

cloudflared 跑在 VPS 上,负责把 VPS 和 Cloudflare 连接起来。

第三层,创建或复用 Cloudflare Tunnel。

Tunnel 的作用是让 Cloudflare 收到访问请求后,可以把请求转发到 VPS 上的本地 WebUI。

第四层,把子域名绑定到 Tunnel。

用户访问自己的 HTTPS 域名。这个域名指向 Cloudflare Tunnel,不指向 VPS 开放端口。

第五层,给这个域名加 Cloudflare Access。

Access 的作用是验证谁能访问。我的场景里,用邮箱验证就够了。更复杂的团队场景,也可以换成身份提供商、群组策略或更严格的访问规则。

第六层,做手机端验证。

一定要用手机浏览器实际打开一次。不要只在电脑上测。手机浏览器、邮箱 App、Cookie、验证链接跳转,都可能影响最终体验。

第七层,排查兼容性。

像 Hermes WebUI 这种应用,可能会用到 SSE 长连接和比较严格的 CSP。接到 Cloudflare Tunnel 和 Access 后,如果出现页面能验证却打不开后端,就要分层看日志。

如果出现 Unable to connect to origin

我这次遇到过类似问题。

浏览器页面可能会提示:

Unable to connect to origin

这句话不能只按字面理解。

它可能来自很多层:

WebUI 进程不在
本地端口没有监听
cloudflared 服务异常
Tunnel 没有 active connection
ingress 指向了错误端口
Access 应用类型或域名配置不对
SSE 长连接被代理层取消
CSP 拦截了 Cloudflare Access 相关资源

所以排查时不要盯着浏览器页面硬猜。

更有效的顺序是:

先看 WebUI 本地是否健康
再看 cloudflared 是否运行
再看 Tunnel 是否连上 Cloudflare
再看 Access 应用和策略
最后看 SSE、CSP、HTTP 连接兼容性

有些配置项和字段名会随 cloudflared 版本、Cloudflare 文档更新而变化。涉及 origin 连接参数时,建议以当前官方文档和本机 cloudflared 版本为准,不要盲目复制旧配置。

AI 时代,人应该负责什么

这件事做完以后,我有一个很强的感受:在 AI 时代,很多技术问题不再要求人记住每一条命令。

人更应该负责三件事:目标、边界、验收。

第一,定义目标。

这件事的目标要写清楚:

手机和电脑都能访问
必须使用 HTTPS 域名
Hermes WebUI 不能直接开放公网端口
访问前必须有身份验证
修改后必须能验证结果

第二,定义边界。

边界不需要在正文里写成一大串吓人的安全清单。正文讲清楚三条就够了:

不泄露凭据
不开放公网端口
不破坏现有配置

具体到给 AI Agent 的任务提示,可以再把这些边界写细一点。因为 Agent 真的会执行命令、读取文件、修改服务,它需要明确知道哪些东西不能输出,哪些动作不能做。

第三,定义验收标准。

比如:

Hermes WebUI 正常监听
cloudflared 服务正常
Tunnel 有可用连接
未登录访问会跳到 Cloudflare Access
邮箱验证后能进入 WebUI
日志没有新的 origin 连接错误
手机也能完成验证

这些想清楚后,具体命令、配置、日志排查,就可以交给 AI Agent 做。

我会怎么把任务交给 AI Agent

下面这段提示词可以作为模板。

这里有一个关键点:不用手动填写所有路径。Hermes WebUI 目录、Hermes Agent 目录、Python 路径、当前监听端口,这些信息 AI Agent 可以先在 VPS 上自查。人只需要给出目标域名、Cloudflare 账号状态和允许访问的邮箱。

我有一个 Hermes WebUI 部署在 VPS 上,目前只能通过 SSH 本地端口转发访问。

请你先自查当前环境,包括:

1. Hermes WebUI 是否在运行。
2. Hermes WebUI 当前监听哪个端口。
3. Hermes WebUI 和 Hermes Agent 分别安装在哪里。
4. Hermes 使用的 Python 环境在哪里。
5. cloudflared 是否已经安装。
6. 当前是否已经有可复用的 Cloudflare Tunnel。

我的目标:

1. 让手机和电脑都可以通过自定义 HTTPS 域名访问 Hermes WebUI。
2. 使用 Cloudflare Tunnel 暴露 WebUI。
3. 使用 Cloudflare Access 做访问验证。
4. Hermes WebUI 本身继续只监听 127.0.0.1,不直接开放公网端口。
5. 修改前先检查现状,修改后必须验证。

我提供的信息:

1. 期望访问域名:填写你的域名。
2. Cloudflare 账号已经托管该域名:是或否。
3. 允许访问的邮箱:填写允许访问的邮箱。

安全要求:

1. 不要输出任何 API Token、邮箱验证码、密钥、Access JWT、Tunnel credentials 或 WebUI 密码。
2. 不要直接开放 Hermes WebUI 公网端口。
3. 不要删除现有 Hermes 配置。
4. 修改配置前先说明会影响哪些文件或服务。
5. 如果需要我手动登录 Cloudflare,请给出登录链接和下一步说明。

请你自动完成:

1. 检查 Hermes WebUI 是否能在 VPS 本地正常访问。
2. 检查 cloudflared 是否已安装,没有就安装。
3. 创建或复用 Cloudflare Tunnel。
4. 把指定域名通过 Tunnel 转发到 VPS 本地 Hermes WebUI。
5. 配置 Cloudflare Access,让访问者必须先通过邮箱验证。
6. 检查 cloudflared 服务是否正常运行。
7. 检查 Tunnel 是否有可用连接。
8. 检查 Hermes WebUI 是否存在 SSE 长连接或 CSP 兼容问题。
9. 如有必要,修复配置并重启相关服务。

最后请告诉我:

1. 最终应该访问哪个 URL。
2. 手机端应该如何验证。
3. 你改了哪些文件或服务。
4. 还有哪些需要我手动确认的风险。

这段提示词的关键不在于命令多完整,而在于它把目标、边界、环境和验收说清楚了。

我最后得到的结果

完成以后,我现在无需每次在电脑上开 SSH 本地转发。

我可以直接在手机或电脑浏览器里打开自己的 HTTPS 域名。访问时先进入 Cloudflare Access 验证页,通过邮箱验证后再进入 Hermes WebUI。

对我来说,这件事的价值有两层。

第一,手机能打开 Hermes WebUI。

第二,个人 AI 工作台的入口从临时访问升级成了长期入口。

它有固定域名,有身份验证,不需要直接开放 VPS 端口,也更适合后续持续使用。

结尾

这类问题表面上是技术配置,底层其实是访问方式设计。

本地服务是一层。

公网入口是一层。

身份验证是一层。

日志排查和兼容性修复又是一层。

人把目标和边界讲清楚,AI Agent 去执行、检查、修改和验证。这样做,技术细节没有消失,但它们被放回了正确的位置。

最终结果很简单:

打开自己的 HTTPS 域名
  ↓
通过 Cloudflare Access 验证
  ↓
进入 Hermes WebUI

电脑能用,手机也能用。

而且 WebUI 不需要直接裸露在公网。

相关文章

在 Dokploy 上升级 n8n 的经验分享

n8n 是一款强大的自动化流程工具,随着官方不断迭代升级,保持 n8n 版本的最新不仅可以获得新功能,还能修复已知问题。本文将详细介绍如何在 Dokploy 平台上升级已经部署的 n8n 服务。

修复 Git 提交历史中的作者信息

本文介绍了如何修复 Git 提交历史中的作者信息,包括使用 filter-branch 命令批量修改历史提交记录,以及如何预防类似问题的发生。对于不小心使用私人邮箱提交代码到公司仓库的情况,这篇文章提供了完整的解决方案。