DNS + Network Troubleshooting

We now move from learning how the Internet works to diagnosing why a real website does not work.

The key principle for this entire lesson is:

Troubleshoot from the outside toward the application, one layer at a time.

For your server, the target is:

templates.cresignsys.com

1. The Troubleshooting Ladder

When a website doesn’t open, don’t immediately restart Nginx or reinstall WordPress.

Follow:

1. Domain
   ↓
2. DNS
   ↓
3. IP
   ↓
4. Routing
   ↓
5. Firewall
   ↓
6. TCP port
   ↓
7. Nginx
   ↓
8. TLS
   ↓
9. HTTP
   ↓
10. PHP-FPM
   ↓
11. WordPress
   ↓
12. MySQL
   ↓
13. Filesystem
   ↓
14. Storage

Each layer depends on the previous one.

2. First Question

Start with:

Does the domain resolve?

Run:

dig templates.cresignsys.com

3. A Record

For IPv4 specifically:

dig templates.cresignsys.com A

You want to see an answer similar to:

templates.cresignsys.com.   300   IN   A   <SERVER-IP>

The actual IP should be the public IP that should receive traffic for this website.

4. Simplified Interpretation

If you see:

A → correct server IP

then:

DNS
✓

If you see:

A → wrong IP

then:

DNS
✗

Do not troubleshoot Nginx yet.

5. `+short`

For a cleaner result:

dig +short templates.cresignsys.com A

You may get:

203.0.113.10

Again, this address is illustrative.

6. Check IPv6

Run:

dig +short templates.cresignsys.com AAAA

If there is an IPv6 address, the client may potentially use IPv6.

This introduces an important troubleshooting situation.

7. IPv6 Can Cause Confusing Problems

Suppose DNS contains:

A
 ↓
Correct IPv4

AAAA
 ↓
Incorrect IPv6

Some clients may prefer IPv6.

Then:

Client
 ↓
AAAA
 ↓
Wrong/unreachable IPv6

while IPv4 works perfectly.

Therefore, always inspect both:

A
AAAA

when diagnosing a modern website.

8. Check Nameservers

Run:

dig +short cresignsys.com NS

This tells you the authoritative nameservers.

If you don’t know which DNS provider is controlling your domain, this is one of the first things to inspect.

9. Follow the DNS Hierarchy

Run:

dig +trace templates.cresignsys.com

Conceptually, you should see the chain:

Root
 ↓
.com
 ↓
cresignsys.com
 ↓
Authoritative DNS
 ↓
templates.cresignsys.com

This helps distinguish a DNS delegation problem from a simple record problem.

10. Authoritative vs Resolver

Suppose:

dig templates.cresignsys.com

gives:

OLD-IP

But your DNS control panel shows:

NEW-IP

Don’t immediately assume the DNS provider is broken.

There may be:

Caching

between your machine and the authoritative server.

11. Find the Authoritative Server

Run:

dig +short cresignsys.com NS

Suppose you get:

ns1.example-dns.com
ns2.example-dns.com

Now query one directly:

dig @ns1.example-dns.com templates.cresignsys.com A

This asks:

What does the authoritative DNS server itself say?

12. Compare Results

You can compare:

Recursive resolver
       ↓
templates.cresignsys.com
       ↓
IP-A

with:

Authoritative server
       ↓
templates.cresignsys.com
       ↓
IP-B

If:

IP-A ≠ IP-B

you may be seeing cached old data.

13. DNS Is Working

Suppose:

dig +short templates.cresignsys.com A

returns the correct server IP.

Now move to the next layer.

IP Connectivity

14. `ping`

Try:

ping templates.cresignsys.com

But don’t make this your primary website test.

Why?

Because:

ICMP

can be blocked while:

TCP 443

still works perfectly.

Therefore:

ping fails

does not automatically mean:

website is down

15. What Does Ping Test?

ping generally uses:

ICMP Echo Request

and:

ICMP Echo Reply

Conceptually:

Client
 ↓
ICMP
 ↓
Server
 ↓
ICMP response

It tests a particular form of network reachability.

16. Website Connectivity Needs TCP

HTTPS normally requires:

TCP
 ↓
443

So a better question is:

Can I establish TCP connectivity to port 443?

17. Test TCP 443

From a machine with network access to the server:

nc -vz templates.cresignsys.com 443

Possible successful output might indicate:

succeeded

If it fails:

Connection refused

or:

timed out

those indicate different problems.

18. Connection Refused vs Timeout

This distinction is extremely useful.

Connection refused

Often means:

Host reachable
 ↓
TCP connection arrived
 ↓
No service accepting that port

For example:

Nginx stopped
Port not listening

But firewalls and other network devices can alter exactly what you observe.

19. Connection Timeout

A timeout can indicate:

Packet filtering
Firewall
Cloud security rule
Routing problem
Network failure

The exact cause must be investigated.

20. Cloud Firewall

Your VPS may have multiple security layers.

For example:

Internet
 ↓
Cloud security rules
 ↓
Virtual network
 ↓
VM
 ↓
Ubuntu firewall
 ↓
Nginx

So even if Nginx is listening:

443 LISTEN

the Internet may still be unable to reach it if a cloud firewall blocks TCP 443.

21. Server-Side Firewall

Ubuntu may also use firewall tools such as:

ufw
nftables
iptables

depending on configuration.

For UFW:

sudo ufw status

This is a read-oriented inspection command.

22. Don’t Confuse Firewalls

You may have:

Cloud firewall

and:

Ubuntu firewall

and:

Nginx

all controlling different layers.

Conceptually:

Internet
 ↓
Cloud security
 ↓
Ubuntu networking
 ↓
Local firewall
 ↓
Nginx

23. Check Nginx

Once TCP reachability is established, inspect Nginx.

sudo systemctl status nginx

You want something similar to:

Active: active (running)

24. Test Nginx Configuration

Always know this command:

sudo nginx -t

It checks the Nginx configuration syntax and basic configuration validity.

A successful result typically includes:

syntax is ok
test is successful

25. Why `nginx -t` Is Important

Suppose you edited:

/etc/nginx/sites-enabled/templates.cresignsys.com

and introduced a syntax error.

Nginx may fail to reload.

Then:

DNS ✓
TCP ✓
Nginx ✗

nginx -t helps identify this before attempting a reload.

26. Check Listening Ports

Run:

sudo ss -lntp

Look for:

:80
:443

You may see:

LISTEN ... 0.0.0.0:443

and perhaps:

LISTEN ... 0.0.0.0:80

27. What Does `:443` Tell You?

If you see:

0.0.0.0:443

a process is listening on TCP port 443 on IPv4 interfaces.

You might also see an IPv6 listener such as:

[::]:443

depending on configuration.

28. Find the Process

The -p option can show the process associated with the listening socket, subject to permissions.

For example:

users:(("nginx",pid=...,fd=...))

This connects:

TCP port
 ↓
Socket
 ↓
Nginx process

29. Now Test HTTPS Locally

On the server:

curl -I https://templates.cresignsys.com

This is a very useful test.

It asks for HTTP headers.

A successful response might be:

HTTP/1.1 200 OK

or:

HTTP/2 200

depending on the configuration/protocol.

30. What If Local Curl Works?

Suppose:

curl -I https://templates.cresignsys.com

works on the server.

But your home computer cannot open it.

That suggests the application stack itself may be working locally.

Investigate:

Cloud firewall
Network security
Public routing
DNS
Client network

rather than immediately changing WordPress.

31. What If Local Curl Fails?

Then investigate the server stack.

Possible layers:

TLS
Nginx
PHP
WordPress
Database

depending on the exact error.

32. `curl -v`

For deeper inspection:

curl -v https://templates.cresignsys.com

This can show a useful sequence:

DNS resolution
 ↓
TCP connection
 ↓
TLS handshake
 ↓
Certificate
 ↓
HTTP request
 ↓
HTTP response

This makes it an excellent learning tool.

33. TLS Inspection

Another powerful command is:

openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com

This is particularly useful for understanding TLS.

34. Why `-servername`?

The:

-servername

option sends the hostname using SNI.

This matters when one server hosts multiple HTTPS websites.

Conceptually:

Client
 ↓
TLS ClientHello
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
Correct certificate/configuration

35. What `openssl s_client` Can Reveal

It can help inspect:

Certificate
Certificate chain
TLS version
Cipher
SNI behavior
Handshake

This is one of the best tools for learning what your Let’s Encrypt certificate is actually doing.

36. Check Your Certificate Files

You already have:

/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

and:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

Never display the private key contents.

You can inspect certificate information safely with:

sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -subject -issuer -dates

This can show:

Subject
Issuer
Not Before
Not After

37. Certificate Expiry

Your previous Certbot output showed:

Expires:
2026-11-11

You can independently inspect the certificate dates.

Conceptually:

Certificate
 ↓
Not Before
 ↓
Not After

This is useful for monitoring.

38. Check the Certificate Name

You can inspect SAN information with:

sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -text

Look for:

Subject Alternative Name

You want the requested hostname to be covered.

39. Certificate Chain

Your fullchain.pem contains the server certificate plus intermediate certificates needed for chain presentation.

Conceptually:

Server certificate
       ↓
Intermediate CA
       ↓
Trusted root

The exact chain depends on the certificate authority and current issuance configuration.

40. Important: `privkey.pem`

Do not run commands that print:

privkey.pem

to the terminal for learning purposes.

Never do:

cat /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

and then copy it somewhere.

The private key is secret.

41. Check Nginx’s Certificate Configuration

You can inspect your site configuration:

sudo sed -n '1,240p' /etc/nginx/sites-enabled/templates.cresignsys.com

Look for directives conceptually similar to:

server_name templates.cresignsys.com;

ssl_certificate /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem;

The exact configuration may differ.

42. DNS and Nginx Must Agree

This is a critical rule.

DNS:

templates.cresignsys.com
        ↓
      Server IP

Nginx:

server_name templates.cresignsys.com;

They must refer to the same service.

If DNS points to Server A but the Nginx site exists only on Server B:

Browser
 ↓
Server A
 ↓
Wrong website / error

43. Nginx Root

Your Nginx configuration may contain something like:

root /storage/websites/templates.cresignsys.com/public;

Conceptually:

Hostname
 ↓
Nginx server block
 ↓
Document root
 ↓
Website files

44. Test the Filesystem

Check:

ls -la /storage/websites/templates.cresignsys.com/public

You should see the website files.

For WordPress, you might see:

index.php
wp-admin/
wp-content/
wp-includes/

45. Check Permissions

If Nginx/PHP cannot access the files:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Filesystem
 ↓
Permission denied

Then you may see:

403
500
502

depending on where the failure occurs.

46. PHP-FPM

For WordPress, check PHP-FPM.

First determine your installed PHP version:

php -v

Then list PHP-FPM services:

systemctl list-units --type=service | grep php

You might see something like:

php8.3-fpm.service

The actual version depends on your server.

47. Check PHP-FPM

For example:

sudo systemctl status php8.3-fpm

Use the version actually installed on your server.

The relationship is:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
 ↓
WordPress

48. 502 Bad Gateway

One common WordPress/Nginx error is:

502 Bad Gateway

It can occur when Nginx cannot successfully communicate with the upstream service, such as PHP-FPM.

Conceptually:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 X

Then:

49. 404 Not Found

means the requested resource wasn’t found according to the application/server handling the request.

Possible causes include:

Wrong URL
Wrong root
Wrong rewrite configuration
Missing file
Application routing

50. 403 Forbidden

often indicates access is forbidden.

Possible causes include:

Filesystem permissions
Directory restrictions
Nginx configuration
Application access rules

Don’t assume every 403 is a Linux permission problem.

51. 500 Internal Server Error

generally means the server encountered an internal application/server-side error.

For WordPress, possibilities include:

PHP error
Plugin error
Theme error
Application configuration
Server configuration

52. 502 vs 503

502 Bad Gateway

often points toward an upstream communication problem.

503 Service Unavailable

often indicates that a service is temporarily unavailable or unable to handle the request.

The exact meaning depends on the architecture and configuration.

53. Nginx Logs

One of the most important troubleshooting tools:

/var/log/nginx/

You may have:

access.log
error.log

or site-specific logs depending on your configuration.

54. Access Log

An access log records requests.

Conceptually:

Client
 ↓
GET /
 ↓
Nginx
 ↓
access.log

It can show things such as:

IP
Request
Status code
User agent
Timing information

depending on the log format.

55. Error Log

The error log is especially useful when something goes wrong.

For example:

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

Then make a request from your browser.

You can watch errors appear in real time.

56. `journalctl`

For system services:

sudo journalctl -u nginx

For recent entries:

sudo journalctl -u nginx -n 100

For live logs:

sudo journalctl -u nginx -f

This connects systemd service management with troubleshooting.

57. The Layered Troubleshooting Workflow

Use this sequence:

1. dig
   ↓
2. Check IP
   ↓
3. Test TCP 443
   ↓
4. Check cloud firewall
   ↓
5. Check UFW/firewall
   ↓
6. ss
   ↓
7. nginx -t
   ↓
8. systemctl status nginx
   ↓
9. curl
   ↓
10. openssl s_client
   ↓
11. Nginx logs
   ↓
12. PHP-FPM
   ↓
13. WordPress
   ↓
14. MySQL

58. Don’t Skip Layers

Suppose:

dig

already proves:

DNS ✓

There is no reason to spend an hour investigating DNS.

Move down:

TCP

If TCP works:

TCP ✓

move to:

TLS

This dramatically reduces troubleshooting time.

59. A Real Example

Imagine the browser shows:

ERR_CONNECTION_REFUSED

Investigate:

DNS
 ↓
correct

Then:

TCP 443
 ↓
connection refused

Now inspect:

sudo ss -lntp | grep ':443'

If nothing is listening:

Nginx/TLS listener problem

You don’t need to investigate WordPress yet.

60. Another Example

Suppose:

TCP 443
✓

but browser says:

NET::ERR_CERT_COMMON_NAME_INVALID

Now:

DNS ✓
TCP ✓
TLS certificate identity ✗

Inspect:

openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com

and the certificate configuration.

61. Another Example

Suppose:

DNS ✓
TCP ✓
TLS ✓
HTTP = 502

Now:

Nginx ✓
PHP-FPM/upstream ?

Investigate PHP-FPM and Nginx error logs.

62. Another Example

Suppose:

DNS ✓
TCP ✓
TLS ✓
HTTP = 200

but WordPress displays an error.

Now the network stack is largely working.

Move upward into:

PHP
 ↓
WordPress
 ↓
Plugins/themes
 ↓
MySQL

63. The Most Important Skill

Don’t ask:

“What command fixes my website?”

Ask:

“At which layer does the failure occur?”

That question changes server administration from trial-and-error into engineering.

64. Your Complete Troubleshooting Map

                   WEBSITE
                      │
                      ▼
                   DOMAIN
                      │
                      ▼
                     DNS
                      │
                 ┌────┴────┐
                 ▼         ▼
                A         AAAA
                 │         │
                 └────┬────┘
                      ▼
                     IP
                      │
                      ▼
                   ROUTING
                      │
                      ▼
                CLOUD FIREWALL
                      │
                      ▼
                 UBUNTU FIREWALL
                      │
                      ▼
                    TCP
                      │
                    :443
                      │
                      ▼
                    TLS
                      │
                    SNI
                      │
                      ▼
                   NGINX
                      │
                 ┌────┴────┐
                 ▼         ▼
              STATIC     PHP-FPM
                           │
                           ▼
                       WORDPRESS
                           │
                           ▼
                         MYSQL
                           │
                           ▼
                       FILESYSTEM
                           │
                           ▼
                        STORAGE

65. Practical Exercise

For templates.cresignsys.com, perform these read-only checks in order:

1. DNS

dig +short templates.cresignsys.com A

2. IPv6

dig +short templates.cresignsys.com AAAA

3. Listening port

sudo ss -lntp | grep ':443'

4. Nginx configuration

sudo nginx -t

5. Nginx status

sudo systemctl status nginx --no-pager

6. HTTPS

curl -I https://templates.cresignsys.com

7. TLS

openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com

8. Certificate dates

sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -subject -issuer -dates

9. Nginx errors

sudo tail -n 50 /var/log/nginx/error.log

Don’t paste the private key anywhere.

66. What We Have Learned

You can now distinguish:

DNS problem
≠
Firewall problem
≠
TCP problem
≠
TLS problem
≠
Nginx problem
≠
PHP problem
≠
WordPress problem
≠
MySQL problem

This is one of the most important foundations for becoming capable of managing a real hosting server.

Next Lesson — 029

HTTP From the Deepest Basics

Now that we understand:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS

we can finally study the protocol that actually carries the web request:

HTTP

We will build it from:

Byte
 ↓
Text
 ↓
Request
 ↓
Response
 ↓
Methods
 ↓
Headers
 ↓
Status codes
 ↓
Cookies
 ↓
Sessions
 ↓
HTTP/1.1
 ↓
HTTP/2
 ↓
HTTP/3
 ↓
Browser ↔ Nginx

Then we will inspect a real request to templates.cresignsys.com and see exactly what Nginx receives.

CresignSys Learn — Lesson 028

DNS + Network Troubleshooting

1. The Troubleshooting Ladder

2. First Question

3. A Record

4. Simplified Interpretation

5. +short

6. Check IPv6

7. IPv6 Can Cause Confusing Problems

8. Check Nameservers

9. Follow the DNS Hierarchy

10. Authoritative vs Resolver

11. Find the Authoritative Server

12. Compare Results

13. DNS Is Working

IP Connectivity

14. ping

15. What Does Ping Test?

16. Website Connectivity Needs TCP

17. Test TCP 443

18. Connection Refused vs Timeout

Connection refused

19. Connection Timeout

20. Cloud Firewall

21. Server-Side Firewall

22. Don’t Confuse Firewalls

23. Check Nginx

24. Test Nginx Configuration

25. Why nginx -t Is Important

26. Check Listening Ports

27. What Does :443 Tell You?

28. Find the Process

29. Now Test HTTPS Locally

30. What If Local Curl Works?

31. What If Local Curl Fails?

32. curl -v

33. TLS Inspection

34. Why -servername?

35. What openssl s_client Can Reveal

36. Check Your Certificate Files

37. Certificate Expiry

38. Check the Certificate Name

39. Certificate Chain

40. Important: privkey.pem

41. Check Nginx’s Certificate Configuration

42. DNS and Nginx Must Agree

43. Nginx Root

44. Test the Filesystem

45. Check Permissions

46. PHP-FPM

47. Check PHP-FPM

48. 502 Bad Gateway

49. 404 Not Found

50. 403 Forbidden

51. 500 Internal Server Error

52. 502 vs 503

53. Nginx Logs

54. Access Log

55. Error Log

56. journalctl

57. The Layered Troubleshooting Workflow

58. Don’t Skip Layers

59. A Real Example

60. Another Example

61. Another Example

62. Another Example

63. The Most Important Skill

64. Your Complete Troubleshooting Map

65. Practical Exercise

1. DNS

2. IPv6

3. Listening port

4. Nginx configuration

5. Nginx status

6. HTTPS

7. TLS

8. Certificate dates

9. Nginx errors

66. What We Have Learned

Next Lesson — 029

5. `+short`

14. `ping`

25. Why `nginx -t` Is Important

27. What Does `:443` Tell You?

32. `curl -v`

34. Why `-servername`?

35. What `openssl s_client` Can Reveal

40. Important: `privkey.pem`

56. `journalctl`