How Do I Troubleshoot an Unresponsive Website Hosted on My ECS?
Symptom
Websites running on an ECS might become unreachable for multiple reasons. Check whether the configurations of network, port, firewall, or security group of the ECS are correct.
Fault Locating
If an error is displayed when you access a website, identify possible causes based on the error message.
Identify possible causes based on error code description in Returned Values for General Requests.
If the error message cannot help you locate the fault, record the resource details and fault occurred time. Then, choose Service Tickets > Create Service Ticket in the upper right corner of the management console to submit a ticket.
You can also locate the fault based on the following possible causes which are listed in order of their probability.
If the fault persists after you have ruled out one cause, move on to the next one.
Possible Cause |
Solution |
---|---|
Port communication |
Check whether the web port used by the target website is properly listened to on the ECS. For details, see Checking Port Communication. |
Security group rules |
Check whether the access to the port is allowed in the security group of the ECS. For details, see Checking Security Group Rules. |
Firewall configuration |
Disable the firewall and try again. For details, see Checking the Firewall Configuration. |
Route configuration |
Check whether the gateway configurations in the ECS route table are correct. For details, see Checking the ECS Route Configuration. |
Local network |
Check whether you can use another hotspot or network to access the website. For details, see Checking the Local Network. |
CPU usage |
Identify and optimize the processes leading to high vCPU usage. For details, see Checking the CPU usage. |
Checking Port Communication
Ensure that service processes and ports are in LISTEN state. Table 2 lists the common TCP statuses.
- Linux
Run the netstat -antpu command to check whether the port used by the target website is in LISTEN status,
for example, netstat -antpu |grep sshd.Figure 2 Checking port listening status
- If the port status is LISTEN, go to Checking Security Group Rules.
- If the port status is not LISTEN, check whether the web service process has been started and correctly configured.
- Windows
Perform the following operations to check port communication:
- Run cmd.exe.
- Run the netstat -ano | findstr "Port number" command to obtain the port number used by the process.
For example, run netstat -ano | findstr "80".Figure 3 Checking port listening status
- If the port is in LISTENING state, go to Checking Security Group Rules.
- If the port is not in LISTENING state, check whether the web service process has been started and correctly configured.
TCP Status |
Description |
Application Scenario |
---|---|---|
LISTEN |
Listens for network connection requests from a remote TCP port. |
The TCP server is running properly. |
ESTABLISHED |
Indicates that a connection has been set up. |
A TCP connection is properly set up. |
TIME-WAIT |
Waits until the remote TCP server receives the acknowledgment after sending a disconnection request. |
The TCP connection is disconnected, and this state is cleared in 1 minute. |
CLOSE-WAIT |
Waits for a disconnection request sent by a local user. |
An application program fault leads to an open socket. This state is displayed after the network is disconnected, indicating that a process is in an infinite loop or waiting for certain requirements to be met. To resolve this issue, restart the affected process. |
FIN-WAIT-2 |
Waits for the network disconnection request from a remote TCP server. |
The network has been disconnected and requires 12 minutes to automatically recover. |
SYN-SENT |
Waits for the matched network connection request after a network connection request is sent. |
The TCP connection request failed, which is generally caused by the delayed handling of high CPU usage on the server or by a DDoS attack. |
FIN-WAIT-1 |
Waits for the remote TCP disconnection request, or the acknowledgment for previous disconnection request. |
If the network has been disconnected, this state may not automatically recover after 15 minutes. If the port has been used for a long period, restart the OS to resolve this issue. |
Checking Security Group Rules
- Log in to the management console.
- Under Compute, click Elastic Cloud Server.
- In the ECS list, click the name of the target ECS.
- On the Security Groups tab, view security group rules.
- Click Modify Security Group Rule.
- Configure the rule to allow the access of the port used by the website.
For details, see Configuring Security Group Rules.
Checking the Firewall Configuration
- Linux ECS
The following uses port 80 and CentOS 6.8 as an example.
- Run the iptables -nvL --line-number command to obtain firewall policies.
- Run the following commands to allow access to port 80:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
- Run the service iptables save command to save the added rules.
- Run the service iptables restart command to restart iptables.
- Run the iptables -nvL --line-number command to check whether the added rules have taken effect.
- Disable the firewall and try again.
- Windows ECS
- Log in to the Windows ECS.
- Click the Windows icon in the lower left corner of the desktop and choose Control Panel > Windows Firewall.
- Click Turn Windows Firewall on or off.
View and set the firewall status.
- Disable the firewall and try again.
Checking the ECS Route Configuration
- Linux ECS
- Run the route command to check the routing policy. Ensure that the default route of 0.0.0.0 is destined for the gateway and that the IP address and the gateway are in the same network segment, as shown in the first and third lines in the following figure.
- Run the ifconfig or ip addr command to obtain the ECS IP address.
Figure 4 ifconfig command output
Figure 5 ip addr command output
- Run the route -n command to obtain the gateway in the routing table.
The following is an example just for reference.Figure 6 route -n command output
- Run the route command to check the routing policy. Ensure that the default route of 0.0.0.0 is destined for the gateway and that the IP address and the gateway are in the same network segment, as shown in the first and third lines in the following figure.
- Windows ECS
- Run cmd.exe.
- Run the ipconfig command to obtain the ECS IP address.
Figure 7 ipconfig command output
- Run the route print command to obtain the gateway in the routing table.
Figure 8 route print command output
Checking the Local Network
Try another hotspot or network for access.
If the access is successful, the fault may occur in the local carrier network. In such a case, rectify the local network fault and try again.
Checking the CPU usage
If the bandwidth or vCPU usage of an ECS is too high, website access failures may occur. If you have created an alarm rule in Cloud Eye, the system automatically sends an alarm to you when the bandwidth or CPU usage reaches the threshold specified in the rule.
- Identify the processes leading to a high bandwidth or vCPU usage.
- Check whether the processes are malicious and handle the issue accordingly.
- If the processes are normal, optimize them or modify ECS configurations by referring to General OperationsGeneral Operations for Modifying ECS Specifications.
- If the processes are malicious, stop these processes manually or use a third-party tool to stop them automatically.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot