Troubleshooting and optimization strategies for websites that are inaccessible despite normal DNS resolution.

　　Many website owners encounter this problem after changing servers, migrating websites, or modifying DNS records: DNS resolution is normal, the domain name resolves to the correct IP address, but the website is still inaccessible. Using nslookup or dig, the IP address appears correct, but the browser displays "Cannot access this website," "Connection timed out," "502 error," or even "Connection refused." This type of problem is often more complex than a simple DNS failure because it falls under the troubleshooting scope of the network or server layer.

　　I. First, confirm if the DNS is truly working correctly.

　　The first step is still to verify the resolution.

　　1. Use nslookup to check

nslookup yourdomain.com

　　Example of return:

Name:    yourdomain.com
Address: 1.2.3.4

　　1. Confirm that the IP address matches the current server IP address.

　　2. Use `dig` to view more detailed information.

dig yourdomain.com

　　The key is to look at:

ANSWER SECTION:
yourdomain.com.  300  IN  A  1.2.3.4

　　If the IP address is resolved correctly, it indicates that there is no problem at the DNS layer.

　　Next, check the access path.

　　II. Common Reasons for Website Inaccessibility

　　If DNS is normal but the website is inaccessible, the problems usually fall into the following categories:

• Server port not listening
• Web service not started
• Firewall not allowing access
• Server security group restrictions
• CDN configuration error
• HTTPS certificate error
• Reverse proxy configuration error
• IP blocked or network blocked
• Server resources exhausted
• Website program error

　　We checked each item in order of increasing difficulty.

　　III. Check if the server is listening on the port.

　　Most common cause: The server is not running the web service at all.

　　1. Check port 80.

　　Linux execution:

ss -tulnp | grep 80

　　or：

netstat -tulnp | grep 80

　　Normal output should look like this:

tcp  LISTEN  0  128  0.0.0.0:80

　　If no results are found, it means that Nginx/Apache is not running and the port is not listening.

　　Example of starting the service:

systemctl start nginx

　　Check status:

systemctl status nginx

　　IV. Check the server firewall

　　Even if the service is running, access will still be impossible if the firewall does not allow access to the port.

　　Check the firewall status.

firewall-cmd --list-all

　　If ports 80 or 443 are not included, then permission must be granted:

firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --add-port=443/tcp --permanent
firewall-cmd --reload

　　If using ufw:

ufw allow 80
ufw allow 443

　　V. Check Cloud Server Security Group Rules

　　If using a cloud server (such as Hong Kong, Japan, or Singapore nodes), you also need to check the security group rules.

　　Confirm: Is port 80 open inbound? Is access only allowed from specified IP addresses? Are regional IP addresses restricted?

　　Many website administrators only allow port 22 (SSH) and forget to open ports 80 and 443.

　　VI. Test Port Connectivity

　　Test locally:

telnet yourdomain.com 80

　　or：

curl -I http://yourdomain.com

　　If prompted:

Connection refused

　　This indicates the port is not open.

　　If you receive the following message:

Connection timed out

　　This indicates that the network is blocked or the server is not responding.

　　VII. Check HTTPS and Certificate Issues

　　If a website enforces HTTPS but the certificate is not configured correctly, it will also be inaccessible.

　　Test:

curl -I https://yourdomain.com

　　If returned:

SSL certificate problem

　　This indicates that there is a problem with the certificate.

　　Check Nginx configuration:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/private.key;
}

　　Confirmation: Certificate path is correct, certificate is not expired, domain name matches.

　　VIII. Check if CDN is being used

　　If the domain is connected to a CDN but the origin IP is incorrect, the DNS may be normal, but the website will not open.

　　Check the CDN backend: Is the origin IP correct? Is HTTPS origin pull enabled? Is the port configured incorrectly?

　　Refresh the CDN cache and test again.

　　IX. Check server load

　　If server resources are exhausted, it may also become unresponsive.

　　Check CPU and memory:

top

　　or：

htop

　　Check the load:

uptime

　　If the load average is significantly higher than the number of CPU cores, it indicates that the server is overloaded.

　　Solutions: Upgrade the CPU or memory, optimize the program, enable caching, and use dedicated bandwidth to avoid congestion.

　　Ⅹ. Check Web Logs

　　View Nginx error logs:

tail -f /var/log/nginx/error.log

　　Common errors:

• 502 Bad Gateway
• 504 Gateway Timeout
• connect() failed

　　If it's a 502 error, it's most likely because the backend service isn't running.

　　Check PHP-FPM:

systemctl status php-fpm

　　XI. IP Blocking or Network Restriction

　　Access abnormalities in certain areas may be due to IP blocking, ISP interception, or server IP being blocked. Test with different networks, such as mobile data, overseas nodes, public DNS, or use the ping command. If ping fails, it's likely a network issue.

　　XII. Website Program Errors

　　DNS and server are normal, but the page displays a 500 error. This indicates a program-level problem.

　　Troubleshooting: Is the database connection normal? Have configuration files been modified? Are file permissions correct?

　　Check the PHP error log:

tail -f /var/log/php-fpm/www-error.log

　　Optimization Strategy: How to Prevent Recurrence?

　　Besides troubleshooting, prevention is even more important.

　　1. Before modifying DNS resolution, lower the TTL. Set the TTL to 300 seconds in advance to avoid propagation delays.

　　2. Create a migration checklist. Before migrating servers, confirm that ports are open, firewalls are allowed, security groups are configured, certificates are deployed, and programs have been tested.

　　3. Use monitoring tools. It is recommended to deploy port monitoring, HTTP status monitoring, and CPU load monitoring to detect problems early.

　　4. Use a dedicated bandwidth server. If you are doing cross-border business or AI interface services, network stability is extremely important. Choosing a cloud server with optimized lines for China or CN2 lines can reduce access anomalies caused by network fluctuations.

　　If DNS resolution is normal but the website is inaccessible, it is essentially a problem in some link of the "network access chain." As long as you check layer by layer according to the logic in this article, you will definitely find the problem. For website owners, the real skill is not avoiding mistakes, but establishing a standardized troubleshooting process. When you are familiar with these steps, website troubleshooting will no longer be chaotic, but will be resolved in an orderly manner.