开发工具CLI人工智能AI 应用浏览器控制GUI 自动化【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址https://gitcode.com/gh_mirrors/ope/OpenCLI点击查看免费下载本篇技术指南围绕 OpenCLI 的远程编排Remote Orchestration能力展开当 CI Runner、Agent 服务器或沙箱等远端机器需要驱动一个已登录的浏览器会话而登录态Cookie只存在于你本地笔记本的 Chrome 中时如何通过 SSH 反向端口转发或 frp 反向代理让远端opencli进程照常访问自己的localhost:19825背后却把流量隧送回本机 Daemon 与 Chrome。读完本文你将掌握三端同机 反向隧道这一安全模式的完整配置、验证手段与注意事项并能从源码层面理解为什么它比扩展直连远端 Daemon更安全。适用场景什么时候需要远程编排OpenCLI 的默认架构是CLI → Daemonlocalhost:19825→ Chrome 扩展在同一台机器上闭环运行。当你把命令执行点搬到远端时会出现三类典型诉求登录态复用自主 Agent如 OpenClaw、CI 任务或服务端脚本需要驱动一个已登录的浏览器会话但只有你本地 Chrome 保存着目标站点的 Cookie出口 IP 可控目标站点做 IP 维度限流或风控你希望 Web 流量从家庭/办公网络出口发出而不是从 Agent 所在的数据中心 IP 发出远端无浏览器远端机器没有显示器也没有安装 Chrome无法承载扩展。在这三种情况下都需要让远端的opencli进程触达你本机的 Daemon而不是在远端重建一套浏览器环境。反模式警告不要让扩展直连远端 Daemon面对远端要连 Daemon的需求第一直觉往往是让扩展去连远端 Daemon——在插件弹窗里填入公网地址、用 frp 把 19825 端口暴露到公网似乎就完成了。这个方案必须否决原因直接写在源码里Daemon 的 WebSocket 协议没有内置鉴权。在 daemon.ts 的架构注释中安全模型是针对浏览器侧 CSRF 的纵深防御Origin 检查——拒绝来自非chrome-extension://origin 的 HTTP/WS 请求自定义请求头——要求X-OpenCLI头浏览器无法在缺少 CORS 预检的情况下携带它而预检会被拒绝命令端点不返回 CORS 头——仅/ping对 Browser Bridge 扩展 origin 可读用于扩展探测 Daemon 可达性1 MB 请求体大小上限防止内存耗尽WebSocketverifyClient——在连接建立前就拒绝升级请求。这套防御设计的前提是请求来自本地浏览器扩展。一旦端口暴露到公网任何能触达该端口的攻击者都可以读取你已登录的所有站点的 Cookie在任意标签页中执行任意 JavaScript截图、发送任意 HTTP 请求、导出页面内容。因此请像对待未上锁的桌面一样对待 Daemon 端口永远不要把它放到一个你不完全信任的网络上。事实上原生扩展连接远端 Daemon的提案曾在 #636 中被提出但被推迟到 Daemon 具备鉴权能力之后——这正是当前架构坚持Daemon 永不离开 localhost的原因。核心模式反向隧道一个 localhost Daemon正确做法是让Chrome、扩展、Daemon 三者全部留在本地机器然后使用反向端口转发reverse port forward使远端进程通过连接自己的localhost:19825触达你的 Daemon。Daemon 本身从不离开 localhost┌─ Local ─────────────────────────────────┐ ┌─ Remote ──────────┐ │ Chrome ↔ Extension ↔ Daemon (127.0.0.1) │ ←┐ │ opencli-cli │ └──────────────────────────────────────────┘ │ │ (talks to │ │ │ localhost:19825)│ reverse tunnel ────────┘ └───────────────────┘ (SSH -R / frpc / VPN)这个模式最优雅的一点是远端的opencli进程不需要任何额外标志、环境变量或扩展改动——它只是连接自己的回环地址而隧道负责把回环流量转发到你的笔记本。源码侧也印证了这一点CLI 侧对 Daemon 的访问全部硬编码指向回环地址。在 daemon-transport.ts 中DAEMON_URL被固定为http://127.0.0.1:19825而 constants.ts 定义了默认端口DEFAULT_DAEMON_PORT 19825且注释明确说明Chrome 扩展只能连接localhost:19825——OPENCLI_DAEMON_PORT环境变量已不再受支持任何非默认端口值都会触发unsupportedDaemonPortEnvMessage并导致进程以 usage error 退出。方案 ASSH 反向端口转发推荐从你的本地机器 SSH 到远端用-R把本地 Daemon 暴露到远端的回环地址ssh -R 19825:127.0.0.1:19825 userremote-server该会话保持期间远端任何进程连接到localhost:19825都会被转发回你本地的 Daemon。远端侧的工作流与本地完全一致不需要任何改动# On the remote server opencli twitter feed opencli browser open https://example.com经验提示-R子句中使用127.0.0.1而非localhost以避免 IPv6 解析造成的连接停滞。长生命周期 Agent 的隧道保活普通 SSH 会话一旦断开隧道即失效。对长时间运行的 Agent 任务改用autossh实现自动重连autossh -M 0 -N -R 19825:127.0.0.1:19825 userremote-server或者在本地侧将隧道封装为 systemd unit / launchd plist随开机自启并在崩溃后自动拉起。为什么方案 A 是安全的Daemon 始终绑定在你机器的127.0.0.1上端口并未暴露到任何网络接口隧道运行在 SSH 的已认证传输层之上——没有引入任何新的认证面如果 SSH 会话中断隧道随之断开远端opencli只会得到连接失败而不会触达某个陈旧的中间端点。方案 Bfrp 反向 TCP 代理当本地到远端无法直接建立 SSHNAT、防火墙限制时可用 frp 通过一个公网中转服务器暴露本地 Daemon。该方案比 SSH 更复杂、失败模式更多——除非有硬性理由否则优先选方案 A。在你控制的公网中转服务器上运行frps在本地机器运行frpc暴露 Daemon 端口 19825# ~/frpc.toml on your local machine serverAddr public-relay-ip serverPort 7000 auth.method token auth.token long-random-token [[proxies]] name opencli-daemon type tcp localIP 127.0.0.1 localPort 19825 remotePort 19825在远端服务器上运行第二个frpc把中转服务器暴露出的端口映射回远端自身的localhost:19825可用stcpvisitor或 plaintcpclient visitor 配对。这样远端的opencli依然只与自己的回环地址通信对远端进程而言隧道完全透明。风险警告必须在 frps 和 frpc 上都配置强auth.token。没有 token 时任何获知中转地址的人都能完全控制你的浏览器把中转服务器暴露的端口绑定到私有接口或用 iptables / 安全组限制访问。Daemon 端口暴露在公网上与之前被否决的 #636 方案风险等同如果你发现自己正在调试 frp 鉴权问题请回到方案 A——它更便宜也更安全。验证远端如何确认 Daemon 可达隧道建立后在远端执行以下命令确认链路贯通# On the remote server curl -sf http://127.0.0.1:19825/ping echo daemon reachable opencli doctor/ping是 Daemon 提供的唯一免 CORS 限制的健康探针端点见 daemon.ts 的路由处理远端的curl只要得到非空响应就说明隧道已经打通远端的opencli doctor应报告与本地 Chrome 中扩展相同的扩展版本号。这里可以补充一点源码细节来理解doctor的判定逻辑在 doctor.ts 中checkConnectivity会把传输层的单命令超时缩短为 8 秒然后向 Daemon 发送一个指向opencli-probe.invalid域的cookies命令作为活体探针——这实际上是一次完整的 CLI → Daemon → WebSocket → 扩展 端到端往返随后getDaemonHealth读取/status端点见 daemon-transport.ts根据profileRequired、profileDisconnected、extensionConnected等状态字段把健康状态归类为stopped/no-extension/profile-required/profile-disconnected/ready。因此远端的doctor报告实际上是远端 → 隧道 → 本机 Daemon → 本机扩展整条链路的健康证明。如果你的本地 Chrome 存在多套浏览器配置注意doctor会像正常命令派发一样先经过 profile 路由解析见 doctor.ts多 profile 且未设默认值时会报告profile-required。注意事项与边界条件本地 Chrome 必须在远端命令执行期间保持运行关闭 Chrome 会同时关闭扩展的 WebSocket远端opencli调用将报 no daemon 错误直到 Chrome 重新打开。这是因为 Daemon 只是转发层真正的浏览器能力全部驻留在扩展侧隧道延迟会叠加到每一次调用上每个浏览器命令都要穿过隧道两次远端 → 本机 → 远端典型 SSH 链路上单次调用增加约 50–200ms 开销跨洋链路上更多。对高吞吐的批量抓取任务建议先在本地评估命令频次与延迟的乘积是否可接受每个本地 Daemon 只能有一条隧道如果你启动了多条同时转发 19825 的 SSH 会话只有第一条生效其余会记录 remote port already in use 警告。使用autossh或 systemd 托管时务必确保单实例。小结编排边界与安全底线OpenCLI 的远程编排本质上遵循一条简洁的边界浏览器生态Chrome 扩展 Daemon永不离开受信任的本地主机远端只通过受认证的传输层隧道间接触达 Daemon 的回环端口。远端opencli无需任何配置改动——这正是 daemon-transport.ts 中回环地址硬编码设计的红利。对绝大多数场景一条ssh -R 19825:127.0.0.1:19825命令即可满足frp 方案仅在 SSH 不可达时作为备选且必须配置强 token 与网络级访问限制。验证时用curl /ping快速探活、用opencli doctor做端到端体检即可确认整条链路处于健康状态。赞分享开发工具CLI人工智能AI 应用浏览器控制GUI 自动化【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址https://gitcode.com/gh_mirrors/ope/OpenCLI点击查看免费下载相关推荐Kubo 如何用 ipfs p2p 把本地 SSH 服务通过 libp2p 隧道转发给远端对等节点Kubo 如何用 ipfs p2p 把本地 SSH 服务通过 libp2p 隧道转发给远端对等节点 本文的目标是把一台机器上运行在 localhost:22网络存储后端OpenCLI Flomo 适配器实战用浏览器登录态把 Flomo 变成命令行opencli flomo memos 全解析OpenCLI Flomo 适配器实战用浏览器登录态把 Flomo 变成命令行opencli flomo memos 全解析 本文聚焦 OpenCLI 中开发工具CLI人工智能AI 应用浏览器控制GUI 自动化OpenCLI 1688 适配器实战指南用已登录浏览器把 1688.com 变成可编程 CLIOpenCLI 1688 适配器实战指南用已登录浏览器把 1688.com 变成可编程 CLI 1688 是国内重要的 B2B 货源平台而 OpenCLI开发工具CLI人工智能AI 应用浏览器控制GUI 自动化上一篇AdvancedNewFile 项目常见问题解决方案下一篇rippledxrpld源码构建完全指南从环境准备到代码生成、覆盖率与 Sanitizers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
