常见问题
请根据您的工作场景参考对应的问题。如果找不到您所需的问题，请联系技术支持。
Websoft9 问题
500 Internal Server Error?
问题描述：查看 websoft9-apphub 容器的日志，出现 500 Internal Server Error
原因分析：websoft9-apphub 容器工作异常或它与被连接的其他微服务通讯异常，运行下面的命令查看错误原因
docker exec -it websoft9-apphub cat /websoft9/apphub/logs/apphub_error.log
Websoft9 核心功能不可用？
当 Websoft9 控制台可以登录，但无法访问应用商店、容器、网关等核心功能时，最大的原因可能是网关工作异常导致应用之间的连接与集成出现了问题。
可运行 docker logs websoft9-proxy 进行诊断。
无法访问 Websoft9 控制台？
常见的原因如下：
- 您的服务器安全组 9000 端口没有开启（最常见因素）
- 安装的不是 Websoft9 的产品
- 你的服务器网络故障
- Websoft9 控制台端口被重置为 9090
- 产品本身的故障导致
- 其他
不管哪种原因，一旦无法出现问题，请第一时刻联系：人工支持
Cokpit 控制台端口被重置为 9090？
用户使用 yum update or apt upgrade 升级操作系统后，可能会导致 Cockpit 的端口被重置为 9090，怎么办？
- 以 9090 端口登录到 Websoft9 控制台
- 设置 > 系统设置 中将端口改为 9090
Websoft9 服务无法启动？
- 先排查计算资源是否异常
# 查看进程
ps aux
# 查看磁盘空间
df -lh
# 查看内存使用
free -lh - 再查看错误日志
# 查看 Websoft9 服务容器日志
docker logs websoft9-apphub
docker logs websoft9-git
docker logs websoft9-proxy
# 查看 Websoft9 服务状态和日志
systemctl status websoft9
journalctl -u websoft9 - 根据错误日志进行诊断
Websoft9 默认端口被占用？
运行 netstat -tunlp 命令，查看服务器上已经使用的端口情况。
Docker service 无法启动？
先通过 systemctl status docker 和 journalctl -xe 查看错误日志。
如果错误日志是 Unit docker.socket entered failed state，表明系统缺少 docker 用户组，运行 groupadd docker 增加用户组
创建应用报错 data.forward_port should be >= 1?
问题现象：重建应用时报错 data.forward_port should be >= 1，但应用重建时成功的
问题原因：重建应用时可能删除 .env 文件中的 W9_URL 和 W9_HTTP_PORT 环境变量，导致重建应用时尝试更新 Websoft9 网关
解决方案：如果应用不需要发布，可以删除应用在 Websoft9 网关中对应的记录
应用问题
访 问应用出现 502 错误？
502 错误全称为 “Nginx 502 Bad Gateway”。错误不在 Nginx 网关本身，而是 Nginx 转发的后端服务运行异常。
后端服务异常包括：
- 计算资源不够
- 后端服务停止运行
- 后端服务端口错误
修改了数据库密码，应用不能访问？
修改了数据库密码，如果应用不能访问。需要通过 应用编排 功能中修改应用的 .env 或 docker-compose.yml 中数据库连接信息。
重建应用后生效。
容器应用无法远程访问？
导致这个问题的可能原因有三点：
- 端口没有正确映射到宿主机
- 容器内部拒绝远程访问
- 服务器安全组对应的端口没有开放
如何清空应用的容器日志？
# 获取容器日志路径
docker inspect --format='{{.LogPath}}' Container_Name
# 清空日志
echo "" > log_path
网站访问很慢？
网站慢最常见的原因包括如下几个方面：
- 访问量太大
- 带宽不够
- 服务器满负荷运转
- 图片、视频、CSS/JS等静态资源太多
经过实践发现，90% 的情况都是由于网络带宽不够导致。
另外针对静态资源较多的情况，我们建议：
- 采用CDN
- 网站图片超过1000张，建议从服务器中分离出去
以上方案简单可靠，降低服务器资源消耗，实现成本较低，效果好。
网站重定向错误导致打不开？
原因分析：死循环或重定向目标不存在
解决方案：分析网站根目录下的 .htaccess 文件，看看有没有死循环规则
应用网络超时？
在使用 WordPress, ownCloud 等应用时，可能出现打开后台、访问页面、在线升级等操作由于网络原因导致失败。
常见网络超时场景：
- 在线升级
- 应用市场安装插件
- 在应用提供商的平台上注册账号
- 程序中的 reCAPTCHA 验证
- Google 地图
- 程序代码中第三方资源（CSS/JS等）
- Docker pull 镜像
- yum / apt 升级
这些场景的根本原因都是一样的，即：应用中的服务无法畅通的访问其上游 。
结果会导致用户无法获取对应的服务，最后只能接受系统超时的结果。
如何解决呢？
既然是网络不通导致，而我们又无法对应用提供商服务器的网络做出任何动作。显然，只有从应用或应用所在的服务器网络情况做出应对，才能探索合适的解决方案：
- 通过 Websoft9 网关的 sub_filter 指令，替换应用中不畅通的 URL
- 修改应用中的代码，将网络不通的服务替换。例如：更换 Docker 仓库地址。
- 临时修改应用自身的网络访问，让应用可以直接与应用提供商服务器连通。例如：在 WordPress 中安装代理插件，临时让 WordPress 访问国外的升级服务器。
- 临时改变自身服务器的网络，使之与应用提供商服务器连通。例如：应用服务器中安装代理客户端，使应用服务器可以通过代理去访问国外升级服务器。
以上提出的方案基本包括涵盖全部场景，但详细操作需根据具体的应用而定。
安全问题
Websoft9 存在病毒、木马和安全漏洞吗？
Websoft9 在上架到云市场时，已经过严格的安全测试，绝对不会默认存在病毒或木马、后门。
但需要澄清的是，仅保证默认不存在，无法保证后续没有漏洞。原因见下一个问题。
云平台为什么不定期提示漏洞？
云平台不定期提醒系统有漏洞或潜在威胁，这是什么原因呢？
软件本身是不断升级迭代发展的，漏洞总是从发现到打补丁的循环中不断成长。镜像中包括：操作系统、中间件、数据库、语言等软件包，没一个软件包都有可能有漏洞。
最新的漏洞就会被发现，云平台就会第一时刻通知到用户，这反而是一件好事。
总而言之，软件的安全是动态系统，软件的本质决定没有人能够在安全上做到“万无一失，疏而不漏”。
另外，从商务角度看，云平台会有监管镜像产品的责任，间接的保障用户的安全：
- 合作选择：保证服务商有丰富的云服务器系统维护和环境配置经验，拥有专业的运维团队；
- 流程控制：要求服务商严格遵循《云平台安全审核标准》，只有通过安全审核的镜像才可以售卖；
- 合规机制：要求服务商须与每一个用户签订《镜像使用许可协议》，对镜像安全向用户作出承诺；
其他问题汇总（表）
除应用自身的故障问题之外，管理员还需关注支持应用的系统组件的故障：
| 组 | 组件 |
|---|---|
| 基础架构 | Docker, Linux |
| 数据库 | MySQL/MariaDB, SQLSever, PostgreSQL, MongoDB, Redis |