OpenClaw 访问故障排查记录
今天 OpenClaw 突然访问不了了，页面一直加载超时，这下正好可以实践一下运维排查流程了，附上完整记录(注:部分ip等信息已作脱敏处理,ip及端口等内容非真实数据)
一、故障概述
- 故障时间：2026年7月9日 14:50 左右（发现时间）
- 故障现象：https://example.com/ 页面加载超时，无法打开
- 影响范围：Web 界面无法访问
- 解决方式：关闭本地代理开关后恢复正常
- 恢复时间：2026年7月9日 14:55 左右
- 根本原因：本地开了代理，干扰了浏览器的 SSL 证书吊销验证流程
二、服务器基本信息
| 项目 | 信息 |
|---|---|
| 云服务商 | UCloud |
| 服务器位置 | 香港（免备案） |
| 公网 IP | 192.0.2.1 |
| 操作系统 | Ubuntu（Docker 容器部署） |
| SSH 端口 | 2222（非默认 22） |
| SSH 用户 | ubuntu（已配密钥免密） |
| 域名 | example.com |
| 部署服务 | OpenClaw（Docker）、Nginx、Let's Encrypt SSL |
三、故障时间线
14:50 - 发现 OpenClaw 网站无法访问，页面加载超时
14:51 - 开始排查，先 SSH 连接服务器
14:52 - 检查 Docker 容器状态：正常运行（healthy）
14:52 - 检查 Nginx 状态：正常运行（active）
14:53 - 检查 SSL 证书：有效（至 2026-10-06，还有 89 天）
14:53 - 测试服务器本地访问：curl http://127.0.0.1:8080/ 返回 200 ✓
14:54 - 测试外部 HTTPS 访问：从服务器访问自身域名正常
14:54 - 从客户端本地测试：curl 报错 CRYPT_E_REVOCATION_OFFLINE
14:55 - 定位问题：Windows 证书吊销检查失败
14:55 - 尝试 OCSP Stapling 方案：服务器也无法访问 OCSP 服务器
14:56 - 确认根因：本地开了代理，干扰 SSL 验证
14:56 - 关闭代理后访问恢复正常
四、排查过程
排查思路说明
遇到 Web 服务访问故障，遵循"自底向上"原则：
- 先确认服务端（容器/进程）是否正常运行
- 再确认 Web 服务器（Nginx）配置和状态
- 然后确认网络层面（端口、防火墙、SSL）是否通畅
- 最后确认客户端（本地网络、浏览器、代理）是否有问题
为什么要按这个顺序？
- 先排除服务端问题，因为服务端挂了就不用往下查
- 服务端正常再查网络层，因为网络是连接客户端和服务端的桥梁
- 最后查客户端，因为客户端环境最复杂，变量最多
第一步：检查服务端状态
执行命令：
ssh -p 2222 ubuntu@192.0.2.1 "docker ps -a | grep -i openclaw"
结果：
容器名: openclaw
状态: Up 7 hours (healthy)
端口映射: 0.0.0.0:8080->8080/tcp
结论： OpenClaw 容器运行正常，healthcheck 通过
遇到的情况：
- 容器状态显示 "healthy"，说明 Docker 健康检查机制正常工作
- 如果显示 "unhealthy" 或 "Exited"，就需要进一步查看容器日志
docker logs openclaw
第二步：检查 Nginx 状态
执行命令：
sudo systemctl status nginx
结果：
Active: active (running)
结论： Nginx 服务正在运行
为什么查这个？
- Nginx 是反向代理，负责将 HTTPS 请求转发给 OpenClaw
- 即使容器正常，Nginx 挂了也会导致访问失败
第三步：检查 Nginx 站点配置
执行命令：
ls /etc/nginx/sites-enabled/
grep -r 'example' /etc/nginx/conf.d/
cat /etc/nginx/conf.d/example.conf
结果：
- 配置文件：
/etc/nginx/conf.d/example.conf - 监听 443 端口（HTTPS）
- SSL 证书路径：
/etc/letsencrypt/live/example.com/ - 反向代理到：
http://127.0.0.1:8080 - WebSocket 支持：已配置 Upgrade 头
- 80 端口自动跳转到 HTTPS
结论： Nginx 配置正确
第四步：检查 SSL 证书状态
执行命令：
sudo certbot certificates
结果：
Certificate Name: example.com
Expiry Date: 2026-10-06 (VALID: 89 days)
结论： SSL 证书有效，不是证书过期问题
为什么查这个？
- 证书过期是最常见的 HTTPS 访问问题
- 但证书有效不代表客户端能正常验证
第五步：测试服务器本地连接
执行命令：
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/
结果： 200
结论： 服务器内部访问 OpenClaw 正常，服务本身没问题
为什么查这个？
- 排除应用层问题
- 如果这里都失败，说明容器内部有问题
第六步：测试外部 HTTPS 访问
执行命令（从服务器执行）：
curl -s -I https://example.com/
结果： HTTP/1.1 200 OK
注意： 这个测试有局限性 - 服务器访问自己的域名走的是本地回环，不代表客户端能访问
第七步：从客户端本地测试（关键步骤）
7.1 DNS 解析测试：
nslookup example.com
结果：解析到 192.0.2.1 ✓
7.2 HTTPS 连接测试：
curl -s -o /dev/null -w '%{http_code}' https://example.com/
结果：exit code 35，返回 000
遇到的问题： curl 返回 exit code 35，这是 SSL 连接错误
查看详细错误：
curl -v https://example.com/
关键错误信息：
schannel: next InitializeSecurityContext failed:
CRYPT_E_REVOCATION_OFFLINE (0x80092013)
这个错误是什么意思？
- Windows 使用 Schannel 作为 SSL/TLS 实现
- Schannel 在握手时会检查证书吊销状态
- 它会访问 OCSP 服务器（如
r3.o.lencr.org）获取吊销列表 - 如果访问不到 OCSP 服务器，就会报
CRYPT_E_REVOCATION_OFFLINE
第八步：验证 OCSP 服务器可达性
执行命令（从客户端）：
curl -s --connect-timeout 10 -I "http://r3.o.lencr.org/"
结果：无响应，连接超时
执行命令（从服务器）：
curl -s --connect-timeout 10 -I "http://r3.o.lencr.org/"
结果：无响应，连接超时
结论： Let's Encrypt 的 OCSP 服务器被 GFW 封锁，客户端和服务器都无法直接访问
第九步：尝试绕过证书验证
执行命令：
curl -k --connect-timeout 10 https://example.com/
结果： 返回 200，页面内容正常
结论： 跳过证书验证后访问正常，问题确认是 SSL 证书验证失败导致
第十步：检查访问日志
执行命令：
grep 'example' /var/log/nginx/access.log | tail -20
结果：
- IP：198.51.100.1
- 最近访问时间：09/Jul/2026:13:56:45
- 返回状态：200
结论： 之前一直正常访问，服务端有成功响应记录
第十一步：最终确认
最后没招了搜索了相关了情况，发现：
- 使用浏览器访问
- 页面加载超时
- 系统设置开启了代理,但是客户端代理软件没开启...
最终确认： 本地开了代理，代理干扰了浏览器的 SSL 证书验证流程，导致超时。关闭代理后访问正常。
五、根因分析
问题链路：
浏览器发起 HTTPS 请求
↓
Windows Schannel 进行 SSL 握手
↓
尝试访问 OCSP 服务器验证证书吊销状态
↓
OCSP 服务器被墙（或代理干扰验证流程）
↓
证书验证超时
↓
页面加载超时
根因： 本地开了代理，代理干扰了浏览器的 SSL 证书验证流程（可能是代理拦截了 OCSP 请求，或者代理本身响应慢）
六、解决方案
关闭代理后访问正常。
七、附：尝试的解决方案（未采用）
1. OCSP Stapling 方案
- 原理： 让 Nginx 服务器预获取 OCSP 响应，附在证书链中返回
- 失败原因： 服务器本身也无法访问 OCSP 服务器
2. 禁用 Windows 证书吊销检查
- 命令：
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Crypto" /v CertificateRevocation /t REG_DWORD /d 0 /f - 风险： 降低安全性，不推荐
八、经验总结
1. 排查顺序很重要
服务端 → 网络层 → 客户端，从简单到复杂
2. 客户端环境要纳入考虑
代理、VPN、防火墙、杀毒软件都可能干扰网络请求。发现"访问不了"，不一定是服务挂了
3. SSL 问题排查要点
- 证书是否过期
- 证书链是否完整
- OCSP 服务器是否可达
- 客户端是否做了证书验证
4. curl 是很好的排查工具
curl -k跳过证书验证curl -v显示详细握手过程curl -w输出连接时间等指标
5. 国内环境特殊性
Let's Encrypt 免费证书虽然好用，但 OCSP 服务器在国内可能被墙，需要考虑 OCSP Stapling 或其他方案
6. 日志是最重要的证据
/var/log/nginx/access.log能看到客户端真实请求/var/log/nginx/error.log能看到服务端错误docker logs <container>能看到应用层日志
九、附录：相关命令速查
# 检查容器状态
docker ps -a | grep <服务名>
docker logs <容器名> --tail 100
# 检查 Nginx
sudo systemctl status nginx
sudo nginx -t
sudo tail -f /var/log/nginx/error.log
# 检查 SSL 证书
sudo certbot certificates
openssl s_client -connect 域名:443 -servername 域名
# 测试网络连通性
nslookup 域名
curl -v https://域名/
curl -k https://域名/ # 跳过证书验证
telnet IP 端口
# 检查防火墙
sudo iptables -L INPUT -n
sudo ufw status
文档结束
评论
暂无评论，来写第一条吧