OpenClaw部署后503错误源于上游链路中断，需依次检查Pod就绪状态、探针配置与端口一致性、Service/Ingress标签匹配及路由指向、ClusterIP连通性，以及容器内应用进程、日志和端口监听状态。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
OpenClaw部署后出现503错误，说明服务容器已启动但上游处理链路中断，Nginx或Traefik等反向代理无法将请求成功转发至OpenClaw后端服务，常见于端口映射错位、健康检查失败或Pod就绪探针未通过。
确认OpenClaw服务Pod状态与就绪条件
执行kubectl get pods -n openclaw，观察Pod状态是否为Running且READY列显示1/1；若READY为0/1，说明就绪探针（readinessProbe）持续失败，Kubernetes拒绝将流量导入该Pod。
运行kubectl describe pod -n openclaw 【pod-name】，重点检查Events末尾是否有“Readiness probe failed”或“Liveness probe failed”条目；同时核对Containers → Ports中暴露的端口是否与deployment.yaml中containerPort一致——【此处端口必须与应用实际监听端口完全相同，否则探针始终超时】。
若probe配置使用httpGet方式，需确保OpenClaw在/healthz路径返回200响应；若返回404或超时，需在应用代码中补全该端点或改用exec探针。
检查Ingress或Service路由配置
方法一：验证Service selector是否匹配Pod标签
执行kubectl get svc -n openclaw，找到openclaw-service，再运行kubectl get pods -n openclaw --show-labels，比对service.spec.selector字段值是否精确等于Pod的labels输出——标签键值对必须逐字匹配，多一个空格或大小写不一致都会导致Endpoints为空。
方法二：确认Ingress规则指向正确Service与端口
运行kubectl get ingress -n openclaw -o yaml，检查spec.rules[].http.paths[].backend.service.name是否为openclaw-service，且service.port.number与service.spec.ports[0].port一致；若使用service.port.name，需确保service中对应port定义了name字段。
方法三：直连Service ClusterIP测试连通性
进入集群内调试Pod（如busybox），执行wget -qO- http://【openclaw-service-clusterip】:【target-port】/healthz —— 若超时或连接拒绝，说明Service未正确关联Endpoint或后端应用未监听该端口。
排查OpenClaw容器内应用启动状态
第一步：获取容器日志
kubectl logs -n openclaw 【pod-name】 -c openclaw-container
第二步：检查关键进程是否存活
执行kubectl exec -n openclaw 【pod-name】 -c openclaw-container -- ps aux | grep -E "(gunicorn|uvicorn|java)" —— 若无主进程输出，说明应用启动失败，需结合上一步日志定位异常（常见于数据库连接超时、配置文件缺失或环境变量未注入）。
第三步：验证端口监听状态
kubectl exec -n openclaw 【pod-name】 -c openclaw-container -- netstat -tuln | grep :【app-listen-port】 —— 若无输出，证明应用未成功绑定端口，此时即使Pod状态为Running，Service也无法转发流量。
