Abstract: 使用 CloudFlare 绕过了浏览器对 SilverBullet 作为 PWA 应用在 HTTP（非本机）访问环境下的限制，另一方面找到了经过 SilverBullet 魔改后 Lua 的使用方法，得以在此应用中呈现更精简、快捷的检索方式。

Tags: #network #lua

---

一、 PWA 触发浏览器的安全策略限制

1. 背景：

为了撰写开发日志，供给日后 TethysOS 的内置系统级 AI 测试，我选择了在 NAS 上部署 SilverBullet 作为日志编辑器。但在部署完成后，直接使用内网 IP 测试访问却失败了。

2. 原理与解决

SilverBullet 的设计本质就是一个 PWA (Progressive Web App) 应用，性质是 “离线可用”、“即开即用”。所有的编辑操作会在浏览器本地环境中进行，操作的是本地的内存 / 缓存，然后再依赖于 Service Worker 同步到部署好的服务器中。

个中的关键在于，PWA 由此具备了能够改写本地剪切板、甚至拦截网络请求的高权限。各大浏览器厂商为了保证安全，强制要求此类应用（其实是它们依赖的 Service Worker）只能在 “安全上下文” (Secure Context) 下运行。它只认识以下两种情况：

• localhost / 127.0.0.1 （本机环境下）
• https:// （加密连接下）

而我在 NAS 中部署它，在内网环境测试时使用的是 http:// 接我的 NAS 在内网中的 IP 地址 + 映射的端口号。结果就是，浏览器给我看了一个 json 页面，显示 redirect: / 。

这是正常的，因为这种访问方式既不是本机，也不是 HTTPS，所以浏览器直接把它的核心功能（前端 JS ）掐断了，导致我只看到了后端的裸数据。

因此我的解决方案是：直接通过 CloudFlare 将它绑定在我自己的 Tunnel 上，然后通过这个公网域名进行访问。这样一来，它会被强制套上一层 HTTPS 的皮，就骗过了浏览器的安全检查。

另：子域名的绑定也有讲究。在没有额外配置的情况下，这个容器是默认走 Bridge 模式的，不能绑“本机”（127.0.0.1）。一定要绑定 NAS 的真实网络地址。不然结果会跟内网访问走 HTTP 的一样，展示一个大白屏或者后端 json 给我看。

这里的核心在于：在 Bridge 模式下，虽然它在容器里，但它可以访问局域网 IP。它从容器里发包出去，找到了 NAS 的网卡地址。而本机地址则不行，因为 cloudflared 本身就是一个 Docker 容器，silverbullet 是另一个 Docker 容器。除非开了 共享宿主机网络（HOST） 模式， 不然找 127.0.0.1 只能往自己所在的容器里找。

---

二、 SilverBullet 查询语法的版本分裂与 Lua 适配

1. 背景：

为了实现“一次写入，处处查询”的知识库架构（例如自动聚合 #network 标签的日志），我需要利用 SilverBullet 的动态查询功能。官方文档中存在两套语法体系：旧版的 Live Query (``) 和新版的 Space Lua (${query})。

在尝试构建动态目录时，我遇到了如下几个问题：

• 旧版 Live Query 使用 HTML 注释语法 ``。在现代前端渲染（包括和 AI 交互时）中，这部分代码会被视为注释直接隐藏，导致调试极其困难。
• 我最初尝试将 SQL 风格的关键字（如 render、as）直接用在了新版 Space Lua (${}) 块中，导致解析器报错。（比如写了${query[[from page where tags = "network" render ...]]}）
• 习惯了高级语言的 + 号拼接字符串，在 Lua 中却导致了 Parse error。Lua 的字符串连接符是 .. 。

2. 原理与解决

为了至少能够稳定运行，我放弃了混合写法，转为 纯原生 Lua 写法。

比起全表扫描 from page，我改用系统优化过的倒排索引 index.tag "标签名"，直接获取目标对象。同时我弃用了 render 模板，直接在查询语句中构造 Markdown 链接字符串，并在构造字符串时使用 Lua 标准操作符。参考的说明书（以当日版本为准）：https://silverbullet.md/Space%20Lua/Lua%20Integrated%20Query。

最终可运行的代码（以查询 network 标签为例）：

${query[[
  from p = index.tag "network" 
  select "[[" .. p.page .. "]]"
]]}

---

三、 总结

这次部署带我复盘了现代 Web 安全架构，并深入理解了 DSL (领域特定语言) 设计 的实战。

网络层面上：在零信任架构（Zero Trust）下，利用 Tunnel 的 Sidecar 模式（边车模式）可以完美解决内网应用 HTTPS 化的痛点，且无需暴露公网端口。
应用层面上：对于 SilverBullet 这种工具，当官方文档处于版本过渡期时，“去 SQL 化”、回归底层的语言特性（Lua）往往是解决语法冲突的最短路径。

ps: 本文为个人经验，具有时效性，仅作记录，不喜勿喷。