Shield CLI 的演进历程，本质上是对“内网访问”这一需求的重新定义。最初，我们将 Shield 定位为安全隧道工具，对标 ngrok 或 frp，核心叙事围绕“加密隧道 + 浏览器渲染远程桌面”展开。然而，随着插件体系的引入（如 MySQL、PostgreSQL、SQLServer 的 Web 客户端）以及未来对 Redis、Kafka、Elasticsearch 等中间件的支持，Shield 的能力边界已远超传统“隧道”范畴。

如果继续以隧道工具自居，不仅会低估产品价值，还会造成用户认知割裂——用户会困惑：“为什么一个隧道工具能管理数据库？”因此，我们需要重新思考 Shield CLI 的产品定位。

从隧道到网关：三层能力架构

基于现状分析，Shield 的核心能力可以抽象为三层架构。这一架构决定了我们不再仅仅是一条管道，而是一个浏览器优先的内网服务网关（Browser-first Internal Service Gateway）。

┌─────────────────────────────────────────────────────┐
│  Layer 3: 服务操作层 (Service Console)              │
│  插件提供 Web 管理界面：数据库、缓存、队列、存储... │
 ├─────────────────────────────────────────────────────┤
│  Layer 2: 协议转 Web 层 (Protocol → Browser)        │
│  SSH 终端、RDP 桌面、VNC 屏幕 → 浏览器渲染         │
 ├─────────────────────────────────────────────────────┤
│  Layer 1: 安全接入层 (Secure Tunnel)                │
│  加密隧道、零 VPN、端到端安全                       │
 └─────────────────────────────────────────────────────┘

1. 安全接入层 (Secure Tunnel)：这是基石，提供加密隧道和端到端安全，实现零 VPN 接入。
2. 协议转 Web 层 (Protocol → Browser)：将传统的 SSH 终端、RDP 桌面、VNC 屏幕直接映射为浏览器可渲染的内容。
3. 服务操作层 (Service Console)：通过插件体系，为数据库、缓存、队列等内部服务提供原生的 Web 管理界面。

核心叙事：无需客户端的统一入口

Shield 的新定位旨在传达一个核心价值：统一的浏览器入口。用户只需通过一条命令，即可在浏览器中安全访问和操作任何内部服务。

Slogan: Shield — Access any internal service from your browser. No VPN, no client, one command.

这意味着开发者和管理员不再需要安装繁琐的客户端，也不需要记忆每个工具的具体用法，更不需要维持复杂的 VPN 连接。所有的操作体验在浏览器中趋于统一：

shield ssh 10.0.1.5        # 浏览器里开 SSH 终端
shield rdp 10.0.1.10       # 浏览器里开 Windows 桌面
shield mysql 10.0.1.20     # 浏览器里管 MySQL
shield redis 10.0.1.30     # 浏览器里管 Redis
shield kafka 10.0.1.40     # 浏览器里看 Kafka

市场差异化定位

在竞品对比中，Shield 找到了独特的生态位。ngrok 和 frp 专注于隧道，缺乏协议渲染和服务管理能力；Teleport 和 Boundary 虽然实现了零信任访问，但部署复杂度高，主要面向企业运维。

Shield 的独特位置在于 轻量 + 浏览器原生 + 服务可操作。我们不再单纯对标隧道工具，也不追求重型零信任平台的复杂度。通过单二进制部署和低门槛的使用方式，Shield 同时服务于开发者和运维人员，填补了“轻量级浏览器内网网关”的市场空白。

统一体验，统一安全，统一入口。这就是 Shield 作为 Browser-first Internal Service Gateway 的最终愿景。

插件系统架构：按需扩展协议支持

要实现“浏览器优先的内网服务网关”这一愿景，仅靠单一的二进制文件难以覆盖所有潜在的协议与服务。Shield 的核心扩展能力源于其灵活的插件系统架构。这使得 Shield 能够在保持主程序轻量化的同时，按需支持 PostgreSQL、Redis、Kafka 等多样化的协议与服务管理。

独立二进制插件模型

Shield 的插件并非动态链接库，而是独立的二进制可执行文件。这种设计遵循了 Unix 哲学中的“组合优于继承”理念。主程序 shield 负责核心的安全隧道建立、身份认证与 Web 服务托管，而具体的协议解析、业务逻辑交互则卸载给插件处理。

例如，当用户执行 shield postgres 10.0.1.20 时，主程序并不会内置庞大的 PostgreSQL 客户端逻辑，而是调用对应的 shield-plugin-postgres 插件。这种隔离带来了显著优势：

• 安全性：插件运行在独立的进程中，即使插件出现内存错误或崩溃，也不会影响主隧道的稳定性。
• 更新灵活：新增协议支持或修复特定协议 bug 时，用户只需更新对应的插件文件，无需重新下载主程序。
• 语言无关：插件可以使用任何语言编写，只要遵循标准的通信协议即可。

基于 stdin/stdout 的 JSON 通信机制

主程序与插件之间通过标准的输入输出流（stdin/stdout）进行通信，数据交换格式为 JSON。这种设计极大地简化了插件的开发复杂度，同时保证了通信的高效性与可读性。

通信流程大致如下：

1. 握手与配置：主程序启动插件进程，并通过 stdin 发送初始化配置（如目标地址、认证凭据、隧道端口）。
2. 事件驱动：插件处理业务逻辑（如连接数据库、执行查询），将结果或状态更新通过 stdout 以 JSON 形式返回给主程序。
3. Web 渲染：主程序接收插件的 JSON 数据，将其转换为 WebSocket 消息推送至浏览器前端，实现界面的实时交互。

以下是一个简化的通信示例，展示了主程序向插件请求数据库列表的过程：

// Main Program -> Plugin (stdin)
{
  "action": "start",
  "config": {
    "host": "127.0.0.1",
    "port": 5432,
    "user": "appshield",
    "pass": "appshield123",
    "database": "casdoor",
    "readonly": false
  }
}

// Plugin -> Main Program (stdout)
{
  "status": "ready",
  "web_port": 62829,
  "name": "PostgreSQL Web Client",
  "version": "0.1.0"
}

这种松耦合的通信机制，使得 Shield 能够轻松集成第三方工具。开发者无需深入理解 Shield 的内核代码，只需按照协议规范编写一个能够处理 JSON 流的可执行文件，即可将其纳入 Shield 的生态体系。

插件存储与发现

为了便于管理，Shield 约定了标准的插件存储位置。默认情况下，主程序会在启动时扫描特定目录下的可执行文件，自动注册可用的插件能力。

• 内置路径：主程序二进制同级的 plugins/ 目录。
• 用户路径：用户配置目录下的 ~/.shield/plugins/。

这种分层存储结构既保证了官方插件的稳定性，也允许高级用户开发私有插件以满足特定内部协议的需求。系统会自动识别符合命名规范（如 shield-plugin-*）的可执行文件，并将其能力映射到 CLI 命令与 Web 界面中。

可视化管理界面

除了命令行调用，Shield 的 Web UI 提供了直观的插件管理视图。用户可以在浏览器中查看当前已加载的插件列表、版本信息以及状态监控。

图片说明：展示 Shield Web 管理界面中的插件列表页面，包含插件名称、版本、状态开关及资源占用情况。

在管理界面中，运维人员可以按需启用或禁用特定协议支持。例如，对于不需要数据库管理权限的开发环境，可以暂时禁用 mysql 或 postgres 插件，从而缩小攻击面，贯彻最小权限原则。

架构价值总结

通过独立二进制插件与标准化 JSON 通信，Shield 成功构建了 Layer 3: 服务操作层。这不仅解决了“一个隧道工具为什么能管数据库”的认知割裂问题，更从架构上确立了其作为 Browser-first Internal Service Gateway 的扩展基石。

无论是现有的 SSH、RDP 远程访问，还是未来的 Kafka 消息队列洞察、Elasticsearch 日志检索，都可以通过这一架构无缝接入。用户无需关心底层实现，只需通过统一的 shield <protocol> <target> 命令，即可获得一致的安全访问体验。

PostgreSQL 插件安装与快速连接

基于前述的架构设计，让我们通过一个具体的场景——PostgreSQL 数据库管理，来体验 Shield 如何将"Layer 3 服务操作层”落地。不同于传统客户端需要下载驱动、配置连接字符串或通过 SSH 隧道转发端口，Shield 将这一过程简化为标准的 CLI 指令，真正实现了 Browser-first 的访问体验。

插件化安装

Shield 采用模块化设计，核心二进制文件保持轻量，特定协议支持通过插件动态加载。这种设计既保证了启动速度，又允许用户按需扩展能力。对于 PostgreSQL 支持，只需执行以下命令：

shield plugin add postgres

执行后，CLI 会自动从远程仓库拉取对应的插件二进制文件并注册到本地环境。这一过程类似于包管理器的操作，但对用户屏蔽了复杂的路径配置和依赖处理。

一键连接与端口解析

安装完成后，访问数据库无需任何中间件配置。用户只需使用统一的协议前缀命令即可发起连接：

shield postgres 192.168.1.100:5432

为了进一步提升效率，Shield 内置了智能的端口解析逻辑：

1. 默认端口适配：当命令中未显式指定端口时，CLI 会自动解析为该协议的标准端口。对于 PostgreSQL，这意味着 shield postgres 192.168.1.100 等同于 shield postgres 192.168.1.100:5432。
2. 别名与主机名支持：目标地址不仅支持 IP 地址，也支持可解析的域名或内部服务别名（如 shield postgres db-prod）。这使得该命令可以轻松集成到现有的 DNS 或服务发现体系中。

浏览器原生体验

命令执行后，Shield 会在本地建立一个安全的安全隧道，并自动打开默认浏览器指向本地的一个随机高位端口（如 http://127.0.0.1:8080）。此时，用户看到的不再是命令行输出，而是一个功能完整的 Web 版 PostgreSQL 管理界面。

这种交互模式完美契合了 “No VPN, no client, one command” 的核心叙事。运维人员无需在本地安装 pgAdmin 或 DBeaver，也不必担心本地环境缺少依赖库。所有的协议解析、渲染逻辑都在浏览器端完成，而数据传输则通过 Shield 建立的加密隧道进行保护。

通过这种标准化的操作流，PostgreSQL 的管理体验与之前提到的 SSH、RDP 访问保持了一致性。无论是临时排查生产环境数据，还是日常的开发调试，用户只需记住 shield <protocol> <target> 这一种模式，即可覆盖绝大多数内部服务的访问需求。

灵活的身份认证机制

在实现了“一行命令访问服务”的极简体验后，安全性依然是 Shield 不可妥协的底线。作为 Browser-first Internal Service Gateway，Shield 不仅要解决“连通性”问题，更要确保“合法性”。为了适配日常运维与自动化脚本的不同场景，Shield 设计了灵活的身份认证机制，在便捷性与安全性之间取得了平衡。

交互式输入（推荐）

默认情况下，当用户执行数据库连接命令时，Shield 会进入交互式认证模式。这是最符合安全最佳实践的方式。以 PostgreSQL 插件为例：

shield postgres 10.0.1.20

执行后，终端会提示输入认证信息。为了优化交互体验，Shield 做了以下细节设计：

• 用户名默认值：系统默认用户名为 postgres。对于大多数标准部署，用户可直接回车跳过，减少重复输入。
• 密码隐藏输入：在输入密码时，终端不会回显任何字符（包括星号）。这一特性有效防止了“肩窥”（Shoulder Surfing）风险，确保敏感信息不在屏幕留痕。

安全建议：交互式模式是日常手动运维的首选。它避免了敏感凭证出现在 Shell 历史命令（.bash_history）或系统进程列表中，符合最小权限与安全审计原则。

命令行传参（自动化场景）

对于 CI/CD 流水线、定时任务或自动化运维脚本，人工交互显然不可行。Shield 支持通过命令行参数直接传递凭证，实现非交互式登录：

shield postgres 10.0.1.20 --db-user admin --db-pass SecretPassword

这种方式允许脚本无缝集成 Shield 能力，无需人工干预即可完成数据库访问隧道的建立。但需要注意的是，明文密码参数可能会保留在命令历史中，或被其他用户通过 ps 命令查看。

风险提示：在生产环境使用命令行传参时，建议结合环境变量或专用的密钥管理工具（如 Vault），避免硬编码敏感信息。

数据库名可选配置

除了身份凭证，目标数据库名（Database Name）同样支持可选配置。若未在命令中指定，Shield 将默认连接至该用户的默认数据库。这种灵活配置使得同一命令模板可适配多租户或分库架构，无需为每个数据库修改脚本逻辑。

底层安全保障

无论采用哪种认证方式，一旦验证通过，Shield 即刻激活其核心架构中的 Layer 1: 安全接入层 (Secure Tunnel)。

正如产品定位所述，Shield 不仅仅是一个连接工具，更是一个加密网关。认证信息与后续的数据库操作数据，均通过端到端加密隧道传输。浏览器端渲染的 Layer 3: 服务操作层 (Service Console) 与后端数据库之间不存在直接的网络暴露。这种设计确保了即使在公共网络环境下，凭证与数据依然处于严密保护之中，完美践行了 “No VPN, no client, one command” 的安全承诺。

Web 管理界面核心功能

当安全隧道建立完毕后，用户将迎来 Shield 最具价值的体验层——Layer 3: 服务操作层 (Service Console)。不同于传统的本地客户端（如 DBeaver、Navicat），Shield 将所有管理能力收敛至浏览器窗口，实现了真正的“零客户端”运维。

正如产品定位所述，Shield 是一个 Browser-first Internal Service Gateway。这意味着你不需要在安装和维护数据库工具上浪费时间，只需通过浏览器即可获取完整的管理能力。

1. 可视化 Schema 浏览

进入界面后，左侧导航栏会自动加载当前数据库的元数据信息。用户可以清晰地查看：

• 数据库列表：快速切换不同 Database。
• 表结构：展开查看字段名、数据类型、索引及约束。
• 视图与存储过程：支持直接预览定义代码。

这种即开即用的浏览体验，特别适合临时排查问题或进行快速数据验证的场景。

2. 交互式 SQL 执行

主工作区提供了功能完备的 SQL 编辑器，支持语法高亮与自动补全。用户可以在此编写复杂的查询语句，并立即查看执行结果。

-- 示例：查询最近活跃的用户
SELECT id, username, last_login 
FROM users 
WHERE last_login > NOW() - INTERVAL '7 days'
ORDER BY last_login DESC;

执行历史会被自动保存，方便后续回溯审计。对于耗时较长的查询，界面提供进度反馈，避免浏览器假死。

3. 结果导出与数据流转

查询结果不仅支持分页浏览，还提供灵活的数据导出功能。用户可以将结果集一键导出为 CSV、JSON 或 Excel 格式。这对于需要离线分析或向其他系统迁移数据的场景尤为实用。

注意：所有导出操作均经过权限校验，确保用户仅能下载其授权范围内的数据。

4. PostgreSQL 专属：ER 图交互

针对 PostgreSQL 用户，Shield 提供了深度的可视化增强功能。除了基础的表结构查看，系统还支持 ER 图（实体关系图）交互。

• 表结构可视化：以图形化方式展示表与表之间的关联。
• 拖拽外键：支持通过拖拽外键字段快速建立或查看关联关系，直观理解数据库设计。
• 动态联动：点击 ER 图中的表节点，可自动定位到 Schema 浏览栏中的对应表结构。

这一功能极大地降低了理解复杂数据库架构的门槛，特别适合新加入项目的开发者快速上手。

安全与体验的统一

值得注意的是，上述所有 Web 界面操作，底层均运行在 Layer 1: 安全接入层 (Secure Tunnel) 之上。浏览器与数据库之间不存在直接的网络暴露，所有的 SQL 语句与结果数据均通过端到端加密隧道传输。

这种设计完美契合了 Shield 的核心叙事：统一的浏览器入口，统一的安全标准。无论是查看 Schema 还是导出敏感数据，用户都在享受便捷 Web 体验的同时，获得企业级的安全防护。

安全访问控制与只读模式

尽管 Web 界面提供了极大的便利，但在生产环境中，安全性始终是第一位的。正如前文所述，Shield 的所有通信均构建在 Layer 1: 安全接入层 (Secure Tunnel) 之上。这意味着浏览器与数据库之间不存在直接的网络暴露，所有的 SQL 语句与结果数据均通过端到端加密隧道传输。这种设计不仅有效防止了中间人攻击与数据窃听，也确保了即使在内网环境中，敏感数据也不会明文传输。

然而，加密传输仅解决了“通道安全”问题，却无法防止“操作风险”。在实际运维场景中，误执行 DELETE 或 UPDATE 语句可能导致灾难性后果。为此，Shield 提供了 只读模式（--readonly），专为审计、排查或非授权访问场景设计。

写操作拦截机制

当用户在启动命令中附加 --readonly 参数时，Shield 会在协议解析层启用严格的安全策略：

shield postgres 10.0.1.20 --readonly

在此模式下，系统会实时分析流经隧道的 SQL 请求。一旦检测到写操作指令（如 INSERT、UPDATE、DELETE、DROP 等），隧道网关会直接拦截该请求并返回错误提示，而不会将其转发至后端数据库。这种主动拦截机制确保了即使攻击者获取了临时的访问链接，也无法对数据进行篡改，从而在源头上保障了数据完整性。

隐身模式与双重防护

为了进一步提升安全性，建议将只读模式与 --invisible 隐身模式 配合使用。--invisible 模式下，隧道服务不会在公共列表中暴露，只有通过精确令牌或授权的用户才能发现并连接。

结合这两种模式，Shield 实现了从“网络接入”到“操作权限”的双重防护：

1. 链路层：端到端加密，防止窃听。
2. 应用层：只读拦截，防止误删。
3. 发现层：隐身模式，防止未授权探测。

当连接成功建立且安全策略生效时，用户界面会明确展示当前的安全状态。这种透明的状态反馈让运维人员能够时刻确认当前会话是否处于受保护状态，真正实现了统一的浏览器入口，统一的安全标准。

开源地址：https://github.com/fengyily/shield-cli

插件仓库：https://github.com/fengyily/shield-plugins

有问题或建议欢迎提 Issue。