Help Center/ Elastic Cloud Server/ Troubleshooting/ General Issues/ How Do I Troubleshoot an Unresponsive Website Hosted on My ECS?
Updated on 2024-02-29 GMT+08:00
View PDF

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.

Figure 1 Fault locating
Table 1 Possible causes and solutions

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 -antp command to check whether the port used by the target website is in LISTEN state.

    For example, run netstat -ntulp |grep 80.
    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:

    1. Run cmd.exe.
    2. 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.
Table 2 Common TCP statuses

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 of time, restart the OS to resolve this issue.

Checking Security Group Rules

If the port used by the target website is denied in the security group, add a rule to the security group to allow the access of the port.
  1. Log in to the management console.
  2. Under Compute, choose Elastic Cloud Server.
  3. On the ECS list, click the ECS for which you want to change the security group rules.
  4. On the Security Groups tab, view security group rules.
  5. Click Modify Security Group Rule.
  6. 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.
    1. Run the iptables -nvL --line-number command to obtain firewall policies.
    2. 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

    3. Run the service iptables save command to save the added rules.
    4. Run the service iptables restart command to restart iptables.
    5. Run the iptables -nvL --line-number command to check whether the added rules have taken effect.
    6. Disable the firewall and try again.
  • Windows ECS
    1. Log in to the Windows ECS.
    2. Click the Windows icon in the lower left corner of the desktop and choose Control Panel > Windows Firewall.

    3. Click Turn Windows Firewall on or off.

      View and set the firewall status.

    1. Disable the firewall and try again.

Checking the ECS Route Configuration

  • Linux ECS
    1. 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.

    2. Run the ifconfig or ip addr command to obtain the ECS IP address.
      Figure 4 ifconfig command output
      Figure 5 ip addr command output
    3. 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
  • Windows ECS
    1. Run cmd.exe.
    2. Run the ipconfig command to obtain the ECS IP address.
      Figure 7 ipconfig command output
    3. 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 using Cloud Eye, the system automatically sends an alarm to you when the bandwidth or CPU usage reaches the threshold specified in the rule.

  1. Identify the processes leading to a high bandwidth or vCPU usage.
    • Windows

      Windows offers multiple tools to locate faults, including Task Manager, Performance Monitor, Resource Monitor, Process Explorer, Xperf (supported by versions later than Windows Server 2008), and full memory dump analysis.

    • Linux

      Run the top command to check the OS running status.

  1. Check whether the processes are malicious and handle the issue accordingly.
    • If the processes are not malicious, optimize their programs or modify ECS specifications.
    • If the processes are malicious, stop these processes manually or use a third-party tool to stop them automatically.
Parent topic: General Issues