服务器运行失败提示(服务器-故障处理-无法访问实例上运行的网站)
服务器运行失败提示(服务器-故障处理-无法访问实例上运行的网站)ECS Windows 实例端口通信问题ECS Linux 实例端口通信问题ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查端口通信问题
注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。
无法访问 ECS 实例上的网站时的分析思路:
-
根据报错情况分析
-
网络通信问题
-
ECS Linux 实例网络通信问题排查
-
ECS Windows 实例网络通信问题排查
-
端口通信问题
-
ECS Linux 实例端口通信问题
-
ECS Windows 实例端口通信问题
-
防火墙配置异常
-
ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常
-
ECS Linux 实例 SSH 无法连接,关闭 iptables 后连接恢复正常
-
重新配置安全组公网规则
网络通信问题
ECS Linux 实例网络通信问题排查
-
执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。
ECS Windows 实例网络通信问题排查
1. 打开 CMD,执行 ipconfig网络检测命令查看 IP 地址。
2. 执行命令 route print通过实例路由表查看网关。
注意:
-
若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。
-
关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。
端口通信问题
ECS Linux 实例端口通信问题
-
执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。
2. 执行下列命令查看服务运行状态:
CentOS6:service sshd status
CentOS7:systemctl status sshd
-
如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务:
CentOS6:service sshd restart
CentOS7:systemctl restart sshd
3.查看 sshd 程序日志
1) 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。
2) 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。
ECS Windows 实例端口通信问题
执行远程端口检测命令:
1) Tasklist /svc | findstr “Ter” 2) netstat –ano | findstr “$PID”
火墙配置异常
ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常
前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。
-
调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。
-
调整后,重新进行远程连接。
ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常
前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。
1. 执行命令 iptables -nvL –line-number
查看防火墙规则:
1)n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。
2)v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。
3)L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。
2. 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak
保存一份原有的 Iptables 文件,避免丢失已设置过策略。)
1)执行命令 iptables -F 清空实例上所有的规则。
2)执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。
3)执行下列命令放行端口 22:
1.iptables -A INPUT -p tcp --dport 22-j ACCEPT
2.iptables -A OUTPUT -p tcp --sport 22-j ACCEPT
4) 执行下列命令指定 IP 访问端口 22:
1. iptables -I INPUT -s 192.168.1.1-p tcp --dport 22-j ACCEPT
说明: 192.168.1.1 为请求端 IP 地址。
5) 执行命令 iptables -L 查看添加的规则是否生效。
6) 执行命令 iptables-save > /etc/sysconfig/iptables保存添加的规则。
3. 执行命令 service iptables restart或 /etc/init.d/iptables restart重启 Iptables。
4. 执行命令 systemctl reboot 重启实例验证配置。
5.重新进行 SSH 连接。
根据报错情况分析
报错情况比较复杂,此处列出比较常见的几种报错内容:
-
403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。
-
403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。
-
403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。
-
403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。
-
403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。
-
403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。
-
403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。
-
403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。
-
403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。
-
403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。
-
403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。
-
403.11 错误是由于密码更改而导致无权查看页面。
-
403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。
-
403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。
-
403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。
-
403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。
-
403.16 错误是由于客户证书不可信或者无效而造成的。
-
403.17 错误是由于客户证书已经到期或者尚未生效而造成的。
-
404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况:
-
无法在所请求的端口上访问 Web 站点。
-
Web 服务扩展锁定策略阻止本请求。
-
MIME 映射策略阻止本请求。
-
网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。
-
跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。
-
某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)
-
网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问
-
502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。
-
503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况:
-
网络管理员可能关闭应用程序池以执行维护。
-
当请求到达时应用程序池队列已满。
-
应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。
-
应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。
-
应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。
-
某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。
-
网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。
-
该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。
-
该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。