Website Not Opening? DNS, SSL and Firewall Checks
When a website is not opening, the issue can be anywhere between the user's browser and the backend application server. This website not opening troubleshooting guide checks the problem layer by layer: DNS, ping, traceroute, TCP port, SSL certificate, HTTP status codes, firewall, WAF, CDN, load balancer, web server logs, and backend application health.
In This Lesson
Troubleshoot an unavailable website from client scope through DNS, routing, TCP, TLS, HTTP, edge controls, and the application. The ordered checks prevent random changes and preserve evidence.
Quick Learning Map
Keep this three-step view in mind as you work through the detailed lesson.
Define the symptom
Record the exact error, affected users, timing, URL, and recent changes.
Walk the dependency chain
Check DNS, path, ports, certificate, HTTP response, proxy, firewall, WAF, and backend.
Fix and re-test
Correct the proven cause, verify externally and internally, and document prevention.
Website Not Opening? DNS, SSL and Firewall Checks at a Glance
Use this summary before moving into the detailed explanations, examples, commands, and checks.
Core focus
Troubleshoot an unavailable website from client scope through DNS, routing, TCP, TLS, HTTP, edge controls, and the application.
Key connection
Define the symptom → Walk the dependency chain → Fix and re-test
Practical outcome
The ordered checks prevent random changes and preserve evidence.
Website Not Opening? DNS, SSL and Firewall Checks: Quick Summary
A website may fail to open because of DNS resolution failure, wrong IP mapping, packet loss, blocked TCP port, SSL certificate error, firewall policy, WAF rule, CDN issue, server overload, backend service failure, or application error.
1. Common Website Not Opening Symptoms
Users may report that a site is down, slow, blank, not loading, showing an SSL warning, redirecting incorrectly, or returning an error page. The exact browser message is the first clue.
| Error | Likely Area | First Check |
|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN | DNS record, domain, nameserver, or resolver issue | Query A, AAAA, CNAME, NS, and authoritative DNS. |
ERR_CONNECTION_TIMED_OUT | Routing, firewall, CDN, WAF, or server reachability | Check traceroute, TCP 443, firewall logs, and CDN origin status. |
ERR_CONNECTION_REFUSED | Port closed or service not listening | Check listener, security group, firewall, and web service status. |
NET::ERR_CERT_DATE_INVALID | SSL certificate validity | Check certificate expiry, SAN, issuer, and served certificate chain. |
403 Forbidden | WAF, permissions, IP restriction, or application rule | Check WAF events, web server rules, and access logs. |
502/503/504 | Reverse proxy, load balancer, backend, or application | Check pool health, upstream connectivity, application logs, and database health. |
2. Confirm the Exact Error and Scope
A user saying "website is not opening" is not enough. A useful problem statement includes URL, error text, user location, network or ISP, start time, affected users, and whether HTTP and HTTPS both fail.
- One user only: check browser cache, local DNS, proxy, VPN, endpoint security, and local firewall.
- One office or ISP: compare DNS results, traceroute, proxy, firewall, ISP routing, and source IP blocks.
- Everyone: check public DNS, CDN, WAF, load balancer, origin server, and backend application.
- Mobile works but office Wi-Fi fails: suspect local DNS, office firewall, proxy, ISP path, or source IP reputation.
3. DNS Troubleshooting Checks
DNS is the first technical layer in a website not opening troubleshooting guide. If the domain does not resolve correctly, the browser cannot reach the web server.
Windows DNS commands
nslookup example.com
nslookup example.com 8.8.8.8Linux DNS commands
dig example.com
dig example.com A +short
dig example.com AAAA +short
dig @8.8.8.8 example.com
dig @1.1.1.1 example.comCheck whether the domain resolves, whether the IP is correct, whether an unwanted IPv6 AAAA record exists, whether the CNAME chain is valid, and whether public DNS differs from internal DNS. Use the DNS Lookup Tool to compare common record types quickly.
4. Ping and Traceroute Checks
Ping is not a final website test because many production sites block ICMP, but it can show DNS resolution, latency, and obvious packet loss. Traceroute helps compare working and non-working network paths.
ping example.com
ping -c 5 example.com
tracert -d example.com
traceroute example.com
tracepath example.comOne or two traceroute stars do not always mean failure. Focus on whether traffic leaves the local network, whether working and failing users take different paths, and whether the final destination or CDN edge is reachable. Use the IP Location Finder to identify the ASN, ISP, and approximate region behind an IP address seen in DNS, firewall logs, or traceroute output.
5. TCP Port 80 and 443 Checks
A website can resolve correctly and still fail if TCP port 80 or 443 is blocked, closed, or not listening.
curl -I http://example.com
curl -I https://example.com
nc -vz example.com 80
nc -vz example.com 443
Test-NetConnection example.com -Port 80
Test-NetConnection example.com -Port 443If port 443 fails, HTTPS cannot open. Possible causes include firewall block, security group block, load balancer listener down, server not listening on port 443, ISP routing issue, CDN/WAF block, wrong NAT, or stopped backend service.
6. SSL Certificate and TLS Handshake Checks
For HTTPS websites, SSL/TLS must complete successfully. If HTTP works but HTTPS does not, focus on SSL certificate, TLS listener, SNI, CDN SSL mode, WAF SSL profile, or load balancer certificate binding.
openssl s_client -connect example.com:443 -servername example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuerCheck certificate expiry, domain match, SAN list, issuer, intermediate chain, private key match, TLS version, and SNI behavior. For a quick browser-based review, use the SSL Checker.
7. HTTP Status Code Checks
HTTP status codes tell you whether the web layer answered and what kind of response it produced.
If the site responds but feels slow, use the HTTP Response & Timing Analyzer CORS TesterTest Origin, preflight, methods, headers, credentials, and browser access policy. to separate DNS, TCP, TLS, TTFB, transfer and redirect time before choosing the next layer to investigate.
curl -I https://example.com
curl -Ik https://example.com
curl -v https://example.com| Status | Meaning | Where to Check Next |
|---|---|---|
| 200 | Website responded successfully. | Check browser cache or page resources if the user still sees a problem. |
| 301/302 | Redirect response. | Check redirect target, HTTP-to-HTTPS logic, and loop risk. |
| 403 | Forbidden or blocked. | Check WAF, permissions, IP restrictions, and application access rules. |
| 404 | Page not found. | Check URL path, virtual host, document root, rewrite rules, and app route. |
| 429 | Rate limited. | Check WAF, CDN, bot protection, and source reputation rules. |
| 500 | Application or server-side error. | Check app logs, web server logs, recent deployment, and database health. |
| 502 | Bad gateway. | Check reverse proxy, load balancer, upstream IP/port, and backend service. |
| 503 | Service unavailable. | Check backend pool, maintenance mode, overload, and service status. |
| 504 | Gateway timeout. | Check slow backend, database delay, upstream timeout, and network path. |
8. Firewall, WAF, CDN, and Load Balancer Checks
Many website failures are not directly on the web server. A typical path is user to ISP, DNS/CDN, firewall, WAF, load balancer, web server, application server, and database.
- Firewall: verify policy match, NAT, route lookup, session creation, deny reason, and return path.
- WAF: check blocked source IPs, bot protection, SSL profile, rule hits, and 403, 406, 429, or 5XX events.
- Load balancer: confirm virtual server, listener, pool member health, monitor port, persistence, and SSL offload.
- CDN: verify DNS points to the CDN, edge cache is not serving an old error, origin is reachable, and SSL mode is correct.
When logs are unclear, use the tcpdump Cheat Sheet to prove whether traffic reached an interface and the Firewall Troubleshooting Checklist to validate policy, NAT, session, and packet-capture evidence.
9. Web Server and Backend Application Checks
If DNS, path, TCP port, SSL, and HTTP edge checks are fine, move to the server and application.
Apache and Nginx
systemctl status apache2
apachectl configtest
tail -f /var/log/apache2/error.log
tail -f /var/log/apache2/access.log
systemctl status httpd
httpd -t
tail -f /var/log/httpd/error_log
systemctl status nginx
nginx -t
tail -f /var/log/nginx/error.log
tail -f /var/log/nginx/access.logApplication and host health
ps -ef | grep node
ss -tulnp | grep node
journalctl -u your-service-name -f
df -h
free -m
topCheck whether the web service is running, the correct port is listening, backend health checks pass, database is reachable, disk is not full, CPU and memory are stable, and logs show the exact 5XX reason.
10. Website Troubleshooting Command Checklist
| Layer | Commands | Good Output Means |
|---|---|---|
| DNS | dig example.com A +shortdig example.com AAAA +shortdig @8.8.8.8 example.com | The name resolves to the expected address from public resolvers. |
| Connectivity | ping example.comtraceroute example.com | You can compare path, latency, and obvious packet loss. |
| TCP port | nc -vz example.com 443Test-NetConnection example.com -Port 443 | TCP 443 accepts connections; if not, check firewall, listener, NAT, or route. |
| SSL | openssl s_client -connect example.com:443 -servername example.com | TLS handshake completes and the served certificate matches the hostname. |
| HTTP | curl -Ik https://example.comcurl -v https://example.com | You can see status code, redirects, headers, TLS details, and connection errors. |
| Server | ss -tulnpsystemctl status nginxtail -f /var/log/nginx/error.log | The service is listening and logs confirm whether the request reached the server. |
11. Common Causes and Fixes
| Cause | Typical Symptom | Fix |
|---|---|---|
| DNS not resolving | NXDOMAIN or browser cannot find host | Verify A, AAAA, CNAME, NS, authoritative DNS, domain status, and recent zone changes. |
| Wrong IP | Site opens old server or wrong app | Correct DNS, check CDN endpoint, compare public/internal DNS, and wait for TTL expiry. |
| TCP 443 closed | HTTPS timeout or refused connection | Check firewall policy, security group, listener, NAT, route, and server binding. |
| SSL certificate error | Browser warning or TLS failure | Renew certificate, install full chain, verify SAN, check SNI, and reload web service. |
| 403 Forbidden | User blocked or access denied | Check WAF rule, IP restriction, file permission, application ACL, and bot policy. |
| 502 Bad Gateway | Proxy cannot reach backend | Check upstream IP/port, backend service, health check, firewall, and app logs. |
| 503 Service Unavailable | No healthy backend or overloaded service | Check pool members, maintenance mode, CPU, memory, queue depth, and deployment status. |
| 504 Gateway Timeout | Backend too slow or unreachable | Check database, slow queries, upstream timeout, application response time, and network path. |
12. Practical Troubleshooting Example
Problem: https://example.com is not opening.
dig example.com A +short
nc -vz example.com 443
curl -Ik https://example.com
openssl s_client -connect example.com:443 -servername example.com
tail -f /var/log/nginx/error.logIf DNS resolves and TCP 443 connects, but curl returns 502 Bad Gateway, the request is reaching the reverse proxy but the backend application is not responding. Check upstream configuration, backend service, application logs, database connectivity, and load balancer health checks.
Website Not Opening? DNS, SSL and Firewall Checks: FAQ
Why is my website not opening but internet is working?
Your internet can be fine while one site fails because of DNS, SSL, firewall, CDN, WAF, load balancer, server, or application problems. Test the site from another network and check DNS, TCP 443, SSL, and HTTP status.
Why does a website open on mobile data but not office Wi-Fi?
This usually points to local DNS, office firewall, proxy, ISP routing, or source IP blocking. Compare DNS answers, traceroute, and firewall logs from both networks.
Why does HTTP work but HTTPS does not?
Check TCP 443, SSL certificate, TLS configuration, virtual host, load balancer SSL profile, CDN SSL mode, and firewall rules.
Can DNS cause website slowness?
Yes. Slow DNS resolution, DNS timeout, wrong resolver, or a broken CNAME chain can delay loading or stop the website from opening.
Should I clear browser cache during troubleshooting?
Yes, but after checking the technical path. Browser cache, cookies, HSTS cache, and old redirects can create user-specific issues.