uc5.0访问不了web

看一下后台的pod运行情况

能 SSH、matrix 进程显示正常，但 Web 页面（UC 5.0 主界面 + Matrix 后台）打不开，基本都是：端口没监听 / 监听在 127.0.0.1、防火墙挡了、kube 容器挂掉、磁盘满 / 内存溢出、证书 /nginx 异常。
下面按顺序一步步排查（H3C U‑Center 5.0，Matrix 为底层平台）。
一、先确认访问地址和端口是否正确
UC5.0 / Matrix 默认端口：
Matrix 后台：https://IP:8443/matrix/ui
UC 主页：一般是 https://IP:8443 或 https://IP（取决于 nginx 配置）
浏览器里直接输入：
plaintext
https://服务器IP:8443/matrix/ui
不要用域名、不要用 VIP 先，直接物理 IP 测试。
二、SSH 登录后，先看端口是否在监听（最常见）
bash
运行
# 查看 8443、443、80、30000 等端口
ss -tuln | grep -E "8443|443|80|30000"
正常应该看到类似：
plaintext
LISTEN 0 100 *:8443 *:*
异常情况
没输出 → nginx/https 服务没起来
只监听 127.0.0.1:8443 → 只能本机访问，外网 / 浏览器打不开
三、检查 matrix 服务和容器状态（关键）
1）看 matrix 服务状态
bash
运行
systemctl status matrix
显示 active (running) 不代表 Web 一定好，只能说守护进程在跑。
2）看 kube 容器是否全正常（Matrix 是容器化的）
bash
运行
kubectl get nodes
kubectl get pods -n matrix
重点：
所有 pod 必须是 Running，不能有 CrashLoopBackOff、Error、Pending。
如果有 pod 异常，查看日志：
bash
运行
kubectl describe pod <pod名> -n matrix
kubectl logs <pod名> -n matrix
常见原因：磁盘满、数据库挂、证书过期、配置错误。
四、检查服务器防火墙 / SELinux
Linux 防火墙会直接挡住 8443/443：
bash
运行
# 看规则
firewall-cmd --list-ports
# 临时开放 8443
firewall-cmd --add-port=8443/tcp
# 或直接停掉测试
systemctl stop firewalld
SELinux 也可能阻止：
bash
运行
setenforce 0
改完再用浏览器访问试试。
五、检查磁盘是否满、inode 是否耗尽（高发）
bash
运行
df -h
df -i
/ 或 /opt/matrix 使用率 100% → 日志 / 镜像塞满，Web 直接挂。
清理旧日志：
bash
运行
rm -rf /opt/matrix/logs/*
rm -rf /var/log/*
六、重启 matrix 和 nginx（应急恢复）
bash
运行
# 重启 matrix（会重启所有容器）
systemctl restart matrix

# 重启 nginx（UC/Matrix 前端代理）
systemctl restart nginx
重启后再观察 pod 是否正常、端口是否监听。
七、浏览器侧问题（最后排查）
换 Chrome/Edge 无痕模式，清缓存、清 COOKIE
用 curl 命令行测试（最准）：
bash
运行
curl -v https://IP:8443/matrix/ui
能返回 HTML 说明服务正常，纯浏览器问题；超时 / 拒绝连接就是服务端问题。
最可能的根因（结合你的现象）
kube 里某个 web/nginx 容器挂了 → matrix 主进程正常，但 Web 不响应。
磁盘满（/opt/matrix） → 容器写不了日志 / 配置，直接异常。
防火墙 /iptables 误删规则 → 8443 端口被挡。

1. 检查 Web 端口监听状态

• 排查命令：使用 netstat -tunlp | grep <端口号> 或 ss -tunlp | grep <端口号>。
• 检查点：
  • 确认 UC5.0 和 Matrix 对应的 Web 端口（例如常见的 80, 443, 8080, 30000 等，具体视你们的实际配置而定）是否处于 LISTEN 状态。
  • 如果端口没有监听，说明 Web 服务进程（如 Nginx, Apache, Tomcat 或应用自带的 Web 进程）已经异常退出。

2. 检查服务器核心资源（CPU、内存、磁盘）

• CPU 与内存：输入 top 命令，查看 CPU 使用率是否长期 100%，或者内存是否耗尽（Swap 频繁使用）。内存耗尽可能会触发系统的 OOM Killer 机制，随机杀掉 Web 服务进程。
• 磁盘空间：输入 df -h 查看磁盘使用率。如果磁盘（特别是日志分区或根目录）达到 100%，Web 服务将无法写入日志或缓存，从而拒绝新的请求。

3. 检查应用进程与容器状态

• 如果是物理机/虚拟机直接部署：使用 ps -ef | grep <应用名> 确认应用进程是否真实存在。有时进程虽然存在，但可能变成了僵尸进程（状态为 Z）或不可中断睡眠（状态为 D），导致无法处理业务。
• 如果是容器化部署（如 Docker/K8s）：UC5.0 和 Matrix 经常采用容器化部署。请运行 docker ps -a 或 kubectl get pods -A，检查对应的 Web 容器或 Pod 是否处于 Running 状态，有没有出现 CrashLoopBackOff 或 Restarting 的情况。

4. 检查内部防火墙策略

• 排查命令：检查系统内部的防火墙规则，如 iptables -nL 或 firewall-cmd --list-all。
• 检查点：确认是否有策略变更，意外拦截了 UC5.0 和 Matrix 的 Web 访问端口。

5. 查看应用运行日志

• 排查方向：进入 UC5.0 和 Matrix 的安装目录，查看 logs 文件夹下的最新日志文件（如 error.log, catalina.out 等）。
• 关注点：寻找是否有 OutOfMemoryError（内存溢出）、Connection refused（数据库或依赖服务连不上）、或者端口冲突等报错信息。