目录
🚀

问题背景
在部署OpenClaw网关时,遇到了典型的服务器环境挑战:
- 无图形界面的Linux服务器,无法进行 http://localhost:18789 的访问
- 只能通过命令行和映射端口访问
- 浏览器安全策略限制某些访问方式
尝试的困境

第一步:CORS配置失败
首次访问Dashboard时报错:
bash
origin not allowed (open the Control UI from the gateway host
or allow it in gateway.controlUi.allowedOrigins)
尝试配置:
bash
gateway.controlUi.allowedOrigins = ["https://yourdomain.com"]
但问题依旧。
第二步:HTTPS的复杂性
随后出现新错误:
bash
control ui requires device identity (use HTTPS or localhost secure context)
需要生成自签名证书、配置SSL参数、重启服务,对运维不熟悉的开发者过于繁琐。
爆发式的解决思路
意识到关键矛盾:浏览器要求安全访问,而服务器只能接受HTTP请求。
这时SSH隧道成为了完美的解决方案:
SSH隧道的工作原理
本地浏览器 → SSH加密隧道 → 远程服务器 → 原始API
命令详解
ssh -N -L 19790:127.0.0.1:18790 root@外网访问IP
- -N:不执行远程命令,专注隧道
- -L:本地端口转发
- 19790:127.0.0.1:18790:转发规则
- root@外网访问IP:目标服务器
最终方案
部署流程
# 1. 建立隧道
bash
ssh -N -L 19790:127.0.0.1:18790 root@外网访问IP
# 2. 浏览器访问
bash
http://外网访问IP:19790/dashboard
3. 完整配置
bash
"gateway": {
"port": 18789,
"mode": "local",
"bind": "lan",
"controlUi": {
"allowInsecureAuth": true,
"dangerouslyDisableDeviceAuth": true,
"allowedOrigins":["http://your IP:port"]
},
核心优势
- 无需HTTPS配置
- 浏览器无需信任证书
- 自动兼容CORS策略
- SSH加密通道保证安全
方案分析
相比其他方案的比较
| 方案 | 难度 | 适用性 |
|---|---|---|
| HTTPS自签名证书 | 高 | 证书管理复杂 |
| 反向代理配置 | 中 | 需修改Nginx配置 |
| SSH隧道 | 低 | 完美适配无界面环境 |
适用场景
- ✅ 内网服务器运维
- ✅ 临时开发环境
- ✅ 需要快速访问控制台
- ✅ 避免复杂的证书管理
结论:对于无界面服务器,SSH隧道是最优雅、最便捷的访问方案,巧妙化解了浏览器安全策略与实际访问能力的矛盾。