Author: cresignsys

CresignSys Learn — Lesson 051
Linux Processes — From Program to Running Service

We now move one layer deeper into Ubuntu.

You have learned:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
But what is Nginx actually doing inside Linux?

It is a process.

The same is true for:
```
mysqld
php-fpm
sshd
cron
certbot
```
1. Program vs Process

These two words are often confused.

Program

A program is software stored on disk.

Example:
```
/usr/sbin/nginx
```
Process

A process is a running instance of a program.

Conceptually:
```
Program on disk
      ↓
    execute
      ↓
Process in RAM
```
2. Simple Example

You have:
```
nginx
```
installed on the server.

That means the program exists.

But it doesn’t necessarily mean Nginx is running.

You can have:
```
Installed ✓
Running ✗
```
3. Running Program

When Linux starts Nginx:
```
nginx program
      ↓
loaded into memory
      ↓
process
      ↓
CPU executes instructions
```
Now Nginx is running.

4. PID

Every Linux process has a:

PID

Process ID.

Example:
```
nginx
PID 1234
```
The PID identifies that running process.

5. Find Processes

Use:
```
ps aux
```
This displays processes currently running.

You can search:
```
ps aux | grep nginx
```
6. top

Another important command:
```
top
```
It provides a continuously updating view of processes and resource usage.

You can see:
```
PID
CPU
RAM
process
```
7. htop

If installed:
```
htop
```
provides a more interactive process viewer.

8. Process Hierarchy

Linux processes can have parent/child relationships.

Conceptually:
```
Parent
  │
  ├── Child
  ├── Child
  └── Child
```
9. PID 1

On modern Ubuntu systems:
```
PID 1
```
is normally:

systemd

You can verify:
```
ps -p 1 -f
```
You may see something like:
```
/usr/lib/systemd/systemd
```
10. Why PID 1 Matters

systemd is responsible for managing much of the system’s startup and services.

Conceptually:
```
Linux boot
    ↓
systemd
    ↓
services
```
11. systemd Starts Services

For example:
```
systemd
   │
   ├── nginx
   ├── mysql
   ├── ssh
   └── php-fpm
```
This is why you can use:
```
systemctl
```
to manage services.

12. systemctl

For Nginx:
```
sudo systemctl status nginx
```
For MySQL:
```
sudo systemctl status mysql
```
For PHP-FPM:
```
sudo systemctl status php8.3-fpm
```
The exact PHP version depends on your installation.

13. Service vs Process

These are not identical concepts.

A:
```
service
```
is an operational unit managed by the service manager.

A:
```
process
```
is a running execution instance.

Conceptually:
```
systemd service
      ↓
starts
      ↓
process
```
14. Installed

Suppose Nginx is installed.

You might have:
```
/usr/sbin/nginx
```
But:
```
systemctl status nginx
```
could show it isn’t running.

Therefore:
```
Installed
≠
Running
```
15. Enabled

Another confusing word is:

enabled

If you run:
```
sudo systemctl enable nginx
```
you are configuring Nginx to start automatically during appropriate system boot.

This does not necessarily mean:
```
Nginx is currently running
```
16. Started

To start it now:
```
sudo systemctl start nginx
```
So:
```
enable
=
start automatically at boot

start
=
start now
```
17. Restart
```
sudo systemctl restart nginx
```
This stops and starts the service.

Use it when you actually need a restart.

18. Reload
```
sudo systemctl reload nginx
```
A reload asks Nginx to reload configuration while trying to preserve existing service availability.

For configuration changes, reload is often preferable to a full restart when supported.

19. Restart vs Reload

Restart
```
stop
 ↓
start
```
Reload
```
running Nginx
 ↓
read new configuration
 ↓
continue serving
```
The exact behavior depends on the service.

20. Nginx Example

Suppose you modify:
```
/etc/nginx/sites-enabled/example.com
```
First:
```
sudo nginx -t
```
If successful:
```
sudo systemctl reload nginx
```
This is safer than blindly restarting after every configuration change.

21. Why nginx -t?

It tests Nginx configuration syntax and related configuration validity.

If there is an error:
```
nginx -t
```
can identify it before you reload.

22. Very Important Workflow

Use:
```
Edit
 ↓
nginx -t
 ↓
If successful
 ↓
reload
 ↓
test website
```
Not:
```
Edit
 ↓
restart
 ↓
hope
```
23. Process Command

You can inspect a process:
```
ps -p PID -f
```
For example:
```
ps -p 1234 -f
```
24. Find Nginx PID
```
pgrep nginx
```
or:
```
pidof nginx
```
25. Process Tree

A very useful command:
```
pstree
```
or:
```
pstree -p
```
This shows process relationships.

26. Why Process Trees Matter

You might see:
```
systemd
 ├─sshd
 ├─nginx
 │   ├─nginx
 │   └─nginx
 ├─php-fpm
 │   ├─php-fpm
 │   └─php-fpm
 └─mysqld
```
This gives you a conceptual picture of the running server.

27. Nginx Master and Worker Processes

Nginx commonly uses a master/worker architecture.

Conceptually:
```
nginx master
     │
     ├── worker
     ├── worker
     └── worker
```
The master handles management responsibilities.

Workers handle client connections and requests.

28. Why Multiple Workers?

A web server needs to handle many simultaneous connections.

Instead of one process doing everything:
```
one process
 ↓
many connections
```
Nginx can distribute work across worker processes.

29. PHP-FPM

PHP-FPM also uses multiple processes.

Conceptually:
```
php-fpm master
      │
      ├── PHP worker
      ├── PHP worker
      ├── PHP worker
      └── PHP worker
```
These workers execute PHP requests.

30. WordPress Request

Suppose:
```
GET /about/
```
requires PHP.

The flow can look like:
```
Browser
 ↓
Nginx worker
 ↓
FastCGI
 ↓
PHP-FPM worker
 ↓
WordPress
```
31. PHP-FPM Worker

A PHP-FPM worker may execute:
```
index.php
```
Then WordPress loads:
```
wp-config.php
WordPress core
theme
plugins
```
and eventually talks to MySQL.

32. MySQL Process

MySQL normally has a main server process, commonly named:
```
mysqld
```
You can inspect it:
```
ps aux | grep mysqld
```
33. SSH Process

When you connect using SSH:
```
ssh user@server
```
the server’s SSH service is typically:
```
sshd
```
There may be multiple processes/threads associated with active SSH sessions.

34. Cron

Linux also runs scheduled jobs.

On modern Ubuntu, scheduled tasks can be managed through several mechanisms, including:
```
cron
systemd timers
```
For example, automated maintenance might run periodically.

35. Certbot / ACME

Your SSL renewal process might use an ACME client such as Certbot.

It may run:
```
periodically
 ↓
check certificates
 ↓
renew when needed
```
The exact mechanism depends on how you installed/configured it.

36. Process Memory

Every process needs memory.

Conceptually:
```
RAM
│
├── Nginx
├── PHP-FPM
├── MySQL
├── SSH
├── systemd
└── other processes
```
37. Why PHP-FPM Can Consume Lots of RAM

Suppose you have:
```
20 PHP workers
```
Each worker can consume memory.

Conceptually:
```
20 workers
 ×
memory per worker
 =
significant RAM usage
```
The actual memory footprint varies by application and workload.

38. Too Many Workers

Suppose the server has:
```
4 GB RAM
```
and you configure too many PHP workers.

You could reach:
```
RAM exhaustion
 ↓
swap
 ↓
slow server
```
or potentially:
```
OOM
 ↓
process killed
```
39. Process CPU

Processes also consume CPU.

You might see:
```
mysqld
CPU 80%
```
or:
```
php-fpm
CPU 90%
```
This helps identify where processing time is going.

40. CPU Percentage Can Be Misunderstood

On a multi-core system, CPU percentages reported by tools can sometimes exceed 100% for a process using multiple cores.

For example:
```
4 cores
```
can produce an aggregate process usage around:
```
400%
```
depending on the tool’s measurement convention.

41. Load Average

Linux also has:

Load Average

Check with:
```
uptime
```
or:
```
top
```
You may see:
```
load average: 1.20, 0.80, 0.60
```
These correspond roughly to:
```
1 minute
5 minutes
15 minutes
```
42. What Does Load Mean?

Load average is not simply CPU percentage.

It reflects the number of tasks that are runnable or waiting in certain uninterruptible states.

So it can reflect:
```
CPU pressure
+
some I/O-related waiting
```
43. Example

Suppose:
```
2 CPU cores
```
and load average:
```
2.0
```
That could indicate approximately full utilization of CPU capacity under certain workloads.

But interpretation requires looking at CPU and I/O metrics too.

44. High Load ≠ Automatically Bad

Suppose:
```
8 cores
load = 4
```
That may be perfectly acceptable.

But:
```
2 cores
load = 15
```
is more concerning.

Always consider CPU count and whether tasks are blocked on I/O.

45. CPU Count

Check:
```
nproc
```
Example:
```
4
```
means Linux reports four available processing units.

46. Process States

Processes can have states such as:
```
R
S
D
T
Z
```
The most important beginner concepts:
```
R
=
running/runnable

S
=
sleeping

D
=
uninterruptible sleep, often waiting on I/O

Z
=
zombie
```
47. Zombie Process

A zombie is a process that has finished execution but whose parent has not yet collected its exit status.

Conceptually:
```
Child
 ↓
finished
 ↓
zombie entry
```
It is not actively consuming CPU like a running process.

48. Why Zombies Exist

The parent process needs to retrieve the child’s termination status.

This is called:

Reaping

Normally, well-behaved process managers handle this.

49. Don’t Panic About One Zombie

A single transient zombie isn’t necessarily a serious problem.

Many persistent zombies may indicate a parent-process bug or management issue.

50. Killing a Process

Linux provides:
```
kill PID
```
This sends a signal to the process.

For example:
```
kill 1234
```
The default signal is generally:
```
SIGTERM
```
51. SIGTERM

SIGTERM means approximately:

Please terminate gracefully.

A process can handle this signal and clean up resources.

This is preferable to immediately forcing termination.

52. SIGKILL

You can use:
```
kill -9 PID
```
This sends:
```
SIGKILL
```
The process cannot catch or gracefully handle SIGKILL.

Use it carefully.

53. Why kill -9 Is Not the First Choice

Suppose:
```
Nginx
```
is stuck.

You could:
```
kill -9
```
but graceful termination is generally preferable.

Use:
```
SIGTERM
```
first when appropriate.

54. Service Restart Is Usually Better

If Nginx is managed by systemd:
```
sudo systemctl restart nginx
```
is generally preferable to manually killing its processes.

systemd understands the service lifecycle.

55. Parent Process

Suppose:
```
PID 100
```
starts:
```
PID 200
```
Then:
```
PPID of 200 = 100
```
PPID means:

Parent Process ID

56. View Parent Process
```
ps -o pid,ppid,cmd -p PID
```
For example:
```
ps -o pid,ppid,cmd -p 200
```
57. Why Parent/Child Matters

If you see:
```
php-fpm master
    ↓
PHP workers
```
you can understand why killing one worker may not permanently solve the problem.

The master may create another worker.

58. Process Lifecycle

A simplified process lifecycle:
```
Created
   ↓
Running
   ↓
Sleeping / Waiting
   ↓
Running
   ↓
Exit
```
The operating system manages these transitions.

59. File Descriptors

Processes interact with files, sockets, pipes, and other resources using:

File Descriptors

Examples:
```
0 = stdin
1 = stdout
2 = stderr
```
Network sockets are also represented through file descriptors.

60. Why This Matters

Nginx may have many open:
```
file descriptors
```
for:
```
client sockets
log files
configuration files
upstream connections
```
61. File Descriptor Limits

A server can have limits on how many file descriptors a process can use.

A high-traffic web server needs appropriate limits.

You can inspect shell limits with:
```
ulimit -n
```
The actual service limits may be configured differently through systemd or other mechanisms.

62. Nginx and Many Connections

Suppose:
```
10,000 clients
```
are connected.

Nginx needs enough:
```
file descriptors
```
and system resources to handle those connections.

This is one reason scalable hosting requires more than just CPU and RAM.

63. Process Scheduling

Linux has a scheduler.

The scheduler decides which runnable tasks get CPU time.

Conceptually:
```
Process A
Process B
Process C
Process D
       ↓
CPU scheduler
       ↓
CPU cores
```
64. CPU Time

Processes share CPU resources.

For example:
```
Nginx
PHP
MySQL
SSH
system tasks
```
all compete for CPU time.

The Linux scheduler manages this.

65. Nice Value

Linux has a concept called:

Nice

It influences process scheduling priority.

A process with a higher nice value generally receives lower scheduling preference relative to processes with lower nice values.

You can inspect process priorities with tools such as:
```
ps
```
66. Don’t Tune Nice Randomly

As a hosting administrator, don’t change process priorities without understanding the workload.

Most services should run with normal scheduling priority.

67. systemd Service States

When you run:
```
systemctl status nginx
```
you might see:
```
active (running)
```
This is the state you generally want for a continuously running web server.

68. Other Important States

You may see:
```
active
inactive
failed
activating
deactivating
```
69. failed

If you see:
```
Active: failed
```
something prevented the service from operating successfully.

Immediately inspect:
```
sudo journalctl -u nginx
```
or:
```
sudo journalctl -u nginx -n 100
```
70. Journal

Ubuntu’s systemd journal stores logs from many services.

Query:
```
journalctl
```
For Nginx:
```
sudo journalctl -u nginx
```
For MySQL:
```
sudo journalctl -u mysql
```
71. Follow Logs

To watch new log entries:
```
sudo journalctl -u nginx -f
```
The:
```
-f
```
means follow.

72. Why Logs Matter

A process saying:
```
failed
```
doesn’t tell you why.

The logs often provide the reason.

For example:
```
configuration error
permission denied
port already in use
missing file
resource exhaustion
```
73. Port Already in Use

Suppose you start a service and see:
```
Address already in use
```
This usually means another process already owns the port.

Check:
```
sudo ss -ltnp
```
For example:
```
:80
```
might already be occupied by Nginx.

74. Two Services Cannot Normally Listen on the Same IP/Port

For example:
```
Nginx → 0.0.0.0:80
Apache → 0.0.0.0:80
```
They cannot both normally bind the exact same address/port combination.

One will fail unless special socket-sharing arrangements are used.

75. This Explains Apache/Nginx Conflicts

If Apache is already listening on:
```
80
```
and you try to start Nginx on:
```
80
```
Nginx may fail.

Check:
```
sudo ss -ltnp | grep ':80'
```
76. Your Server

You previously worked with:
```
Apache
MySQL
Nginx
PHP-FPM
```
Understanding processes helps you determine which software is actually serving traffic.

Don’t assume the installed software is the active software.

77. Example Diagnostic

Website isn’t working.

Run:
```
sudo ss -ltnp | grep ':80'
```
If you see:
```
apache2
```
instead of:
```
nginx
```
then Apache is currently handling port 80.

That immediately changes your diagnosis.

78. Another Example

You expect PHP 8.3:
```
systemctl status php8.3-fpm
```
but Nginx configuration points to:
```
php8.2-fpm.sock
```
Then:
```
Nginx
 ↓
wrong PHP-FPM socket
 ↓
502
```
Process/service knowledge helps you detect this.

79. Unix Socket

PHP-FPM commonly uses a Unix socket such as:
```
/run/php/php8.3-fpm.sock
```
This is not a TCP port.

It is a local IPC endpoint.

80. IPC

IPC means:

Inter-Process Communication

Processes need ways to communicate.

Common mechanisms include:
```
Unix sockets
TCP sockets
pipes
signals
shared memory
```
81. Nginx → PHP-FPM

In your hosting setup, it may look like:
```
Nginx
 ↓
Unix socket
 ↓
PHP-FPM
```
rather than:
```
Nginx
 ↓
TCP Internet connection
 ↓
PHP-FPM
```
The first is local communication.

82. PHP-FPM → MySQL

PHP may then communicate with MySQL using:
```
Unix socket
```
or:
```
TCP
```
depending on the configuration.

For a local MySQL installation, a Unix socket is common.

83. Complete Process-Level Flow

Now combine everything:
```
Browser
 ↓
Internet
 ↓
Nginx worker process
 ↓
PHP-FPM worker process
 ↓
WordPress PHP
 ↓
MySQL server process
 ↓
InnoDB
 ↓
Disk
```
This is the actual running-process view of your hosting stack.

84. Process vs Service vs Port

These three must not be confused.

Process
```
mysqld PID 1234
```
Service
```
mysql.service
```
Port
```
3306
```
They are related but different.

85. Example

MySQL could be:
```
Installed ✓
Service exists ✓
Process running ✓
Port 3306 listening ✗
```
This can happen if MySQL is configured to use a Unix socket or another port.

Therefore:

Running does not automatically mean “listening on 3306.”

86. The Same for Nginx

You could have:
```
Nginx process ✓
```
but:
```
port 443 ✗
```
if the configuration only listens on port 80.

87. The Diagnostic Model

When a service doesn’t work, ask:
```
Is the program installed?
        ↓
Does the systemd service exist?
        ↓
Is the service active?
        ↓
Is the process running?
        ↓
Is it listening on the expected socket/port?
        ↓
Is the firewall allowing it?
        ↓
Does the application respond?
```
This is a professional troubleshooting sequence.

88. Essential Commands

Processes
```
ps aux
```
Search process
```
ps aux | grep nginx
```
Process tree
```
pstree -p
```
Live process monitoring
```
top
```
Interactive monitoring
```
htop
```
Process IDs
```
pgrep nginx
```
Listening ports
```
sudo ss -ltnp
```
Service status
```
systemctl status nginx
```
Service logs
```
sudo journalctl -u nginx
```
Follow service logs
```
sudo journalctl -u nginx -f
```
89. One Command Set to Memorize

For Nginx:
```
sudo systemctl status nginx
```
```
sudo nginx -t
```
```
sudo ss -ltnp | grep ':80'
```
```
sudo ss -ltnp | grep ':443'
```
```
sudo journalctl -u nginx -n 100
```
This five-command sequence can solve many basic Nginx problems.

90. Your Hosting Platform Now Has Another Layer

You previously saw:
```
Network
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL
```
Now expand it:
```
Linux Kernel
      ↓
systemd
      ↓
services
      ↓
processes
      ↓
threads
      ↓
CPU/RAM
```
91. Complete Infrastructure Model
```
                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP/TCP
                            │
                            ▼
                           TLS
                            │
                            ▼
                          NGINX
                       processes
                            │
                            ▼
                        PHP-FPM
                       processes
                            │
                            ▼
                       WORDPRESS
                            │
                            ▼
                         MYSQL
                       processes
                            │
                            ▼
                         INNODB
                            │
                            ▼
                          DISK

          All running under:

                    LINUX KERNEL
                         │
                         ▼
                       SYSTEMD
```
92. Most Important Concept of This Lesson

A server is not just:
```
files + configuration
```
A running server is:
```
software
+
processes
+
memory
+
CPU
+
network sockets
+
files
+
permissions
+
services
```
93. Next Lesson — 052

Linux Memory From the Absolute Basics

We will go underneath the processes and learn:
```
RAM
 ↓
Virtual Memory
 ↓
Pages
 ↓
Physical Memory
 ↓
Heap
 ↓
Stack
 ↓
Shared Memory
 ↓
Cache
 ↓
Buffer
 ↓
Swap
 ↓
OOM Killer
```
Then we’ll connect it directly to your hosting server:
```
Nginx
+
PHP-FPM workers
+
MySQL
+
Ubuntu
+
multiple WordPress websites
```
and learn how to calculate whether your VPS has enough RAM for the number of websites you want to host.
August 13, 2026
CresignSys Learn — Lesson 050
DNS Deep Internals — From Domain Name to Your VPS

We now go deeper into the system that connects:
```
learn.cresignsys.com
        ↓
     IP address
        ↓
   Your VPS
```
DNS looks simple:
```
domain → IP
```
But underneath it is a distributed global database system.

1. What Is DNS?

DNS means:

Domain Name System

Its basic purpose is:
```
Name
 ↓
Address
```
For example:
```
example.com
     ↓
203.0.113.25
```
But DNS does much more than IP lookup.

It also stores information about:
```
Websites
Mail
Subdomains
Verification
Service discovery
Domain delegation
```
2. Why Do We Need DNS?

Computers can communicate using IP addresses.

You could theoretically type:
```
https://203.0.113.25
```
But humans prefer:
```
https://example.com
```
DNS provides the mapping.

3. Domain Name Structure

Take:
```
learn.cresignsys.com
```
Break it down:
```
learn
  .
cresignsys
  .
com
```
Conceptually:
```
learn
=
hostname/subdomain

cresignsys
=
domain name

com
=
top-level domain
```
4. Root of DNS

There is actually an invisible root at the end.

This:
```
example.com
```
can technically be represented as:
```
example.com.
```
The final:
```
.
```
represents the DNS root.

5. DNS Hierarchy

Think of DNS as a tree:
```
.
│
├── com
│    │
│    └── cresignsys
│          │
│          ├── www
│          ├── learn
│          └── shop
│
└── org
```
The root is at the top.

6. Root DNS

At the top are the:

Root Servers

They don’t normally contain the IP address for every website.

Instead, they know where to find the authoritative servers for top-level domains.

For example:
```
Root
 ↓
.com
```
7. TLD

TLD means:

Top-Level Domain

Examples:
```
.com
.org
.net
.in
```
So:
```
cresignsys.com
```
belongs under:
```
.com
```
8. Root → TLD

Suppose a resolver needs:
```
example.com
```
It can conceptually ask:
```
Root:
Who handles .com?
```
The root responds with information about the .com nameservers.

9. TLD → Domain

Then the resolver asks the .com DNS infrastructure:
```
Who is authoritative for example.com?
```
The TLD system responds with the authoritative nameserver information for that domain.

10. Authoritative DNS

Now we reach:

Authoritative Nameserver

This server is responsible for the actual DNS records for the domain.

For example:
```
example.com
 ↓
authoritative DNS
 ↓
A record
 ↓
203.0.113.25
```
11. Three Important DNS Roles

Remember:
```
Root
 ↓
TLD
 ↓
Authoritative
```
But there is another important participant:
```
Recursive Resolver
```
12. Recursive Resolver

Your computer usually does not walk the entire DNS hierarchy itself.

Instead, it asks a recursive resolver.

For example:
```
Browser
 ↓
Operating system
 ↓
DNS resolver
```
The resolver performs the work of finding the answer.

13. Example Resolvers

Common public DNS resolvers include:
```
8.8.8.8
1.1.1.1
```
These are examples, not requirements.

Your ISP, organization, router, or device can use other resolvers.

14. Full DNS Journey

Suppose you enter:
```
https://learn.cresignsys.com
```
Conceptually:
```
Browser
 ↓
Local DNS cache
 ↓
Recursive resolver
 ↓
Root
 ↓
.com
 ↓
cresignsys.com authoritative DNS
 ↓
learn.cresignsys.com record
 ↓
IP address
```
15. But There Is Usually Caching

The resolver may already know the answer.

For example:
```
Resolver
 ↓
Cache
 ↓
IP found
```
Then it doesn’t need to ask root/TLD/authoritative servers again.

This is why DNS is scalable.

16. TTL

DNS records have:

TTL

Time To Live.

For example:
```
TTL = 3600
```
means the record can generally be cached for about:
```
3600 seconds
=
1 hour
```
before the cache should consider it expired and obtain fresh information.

17. Why TTL Matters

Suppose:
```
learn.cresignsys.com
```
currently points to:
```
IP A
```
You change it to:
```
IP B
```
Some recursive resolvers may still have:
```
IP A
```
cached until the TTL expires.

18. DNS Propagation

People often say:

DNS propagation takes time.

More precisely, DNS changes become visible as cached records expire and resolvers retrieve the updated authoritative information.

So it isn’t usually a single global “propagation event.”

19. Example

Initially:
```
TTL = 3600
```
Record:
```
example.com → IP A
```
You change it:
```
example.com → IP B
```
A resolver that cached IP A shortly before the change might continue returning IP A until its cached TTL expires.

Another resolver whose cache has already expired may immediately retrieve IP B.

Therefore different users can temporarily receive different answers.

20. Lower TTL Before Migration

Suppose you know:
```
Website migration
```
is coming.

You can reduce TTL ahead of time.

For example:
```
3600
 ↓
300
```
Then cached answers expire more quickly.

But reducing TTL immediately before a change does not magically invalidate already-cached records; the old TTL remains relevant to caches that already stored the record.

21. DNS Record Types

The important ones for your hosting platform are:
```
A
AAAA
CNAME
MX
TXT
NS
SOA
```
Let’s understand each.

22. A Record

An:

A record

maps a hostname to an IPv4 address.

Example:
```
learn.cresignsys.com
        ↓
A
        ↓
203.0.113.25
```
23. AAAA Record

An:

AAAA record

maps a hostname to an IPv6 address.

Example:
```
learn.cresignsys.com
        ↓
AAAA
        ↓
2001:db8::25
```
24. A + AAAA

A domain can have both:
```
A
 ↓
IPv4

AAAA
 ↓
IPv6
```
Clients may use IPv4 or IPv6 depending on their connectivity and address-selection behavior.

25. CNAME

CNAME means:

Canonical Name

It creates an alias from one DNS name to another DNS name.

Example:
```
www.example.com
        ↓
CNAME
        ↓
example.com
```
The target is a hostname, not an IP address.

26. CNAME vs A

A:
```
www.example.com
 ↓
203.0.113.25
```
CNAME:
```
www.example.com
 ↓
example.com
```
The CNAME target is then resolved.

27. Important CNAME Rule

A CNAME generally cannot coexist with other ordinary data at the same DNS name.

For example, you normally don’t configure:
```
www.example.com
CNAME → example.com
A → 203.0.113.25
```
at the same exact name.

28. MX Record

MX means:

Mail Exchange

It tells mail systems where email for a domain should be delivered.

Example:
```
example.com
 ↓
MX
 ↓
mail.example.com
```
29. MX Has Priority

MX records have preference/priority values.

Example conceptually:
```
10 mail1.example.com
20 mail2.example.com
```
Lower preference numbers generally mean higher priority.

30. TXT Record

TXT records store text data used by many systems.

Common uses include:
```
Domain verification
SPF
DKIM-related data
DMARC-related policies
Other service verification
```
31. SPF

SPF helps specify which mail servers are authorized to send mail for a domain.

It is published using DNS TXT records.

Conceptually:
```
example.com
 ↓
TXT
 ↓
SPF policy
```
32. DKIM

DKIM uses cryptographic signatures for email authentication.

The public key is published through DNS.

Conceptually:
```
Email server
 ↓
DKIM signature
```
and:
```
DNS
 ↓
public DKIM key
```
The receiving system can use the public key to verify the signature.

33. DMARC

DMARC builds on email authentication mechanisms such as SPF and DKIM.

It lets domain owners publish policies describing how receiving mail systems should handle messages that fail authentication checks.

DMARC policies are also published through DNS TXT records.

34. NS Record

NS means:

Name Server

It identifies the authoritative nameservers for a DNS zone.

Conceptually:
```
cresignsys.com
 ↓
NS
 ↓
ns1.example-dns.com
ns2.example-dns.com
```
35. SOA Record

SOA means:

Start of Authority

It contains important information about the DNS zone, including things such as:
```
Primary authoritative server
Zone administrator contact representation
Serial number
Refresh
Retry
Expire
Negative caching TTL
```
36. What Is a DNS Zone?

A zone is an administrative portion of the DNS namespace.

For example:
```
cresignsys.com
```
could be a DNS zone containing:
```
cresignsys.com
www.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com
```
The exact delegation structure determines what is included.

37. Domain vs Zone

These are related but not identical concepts.

A domain is part of the DNS namespace.

A zone is a portion of that namespace managed together by authoritative DNS servers.

This distinction becomes important when managing DNS professionally.

38. Subdomain

For:
```
learn.cresignsys.com
```
the:
```
learn
```
label is a subdomain label under:
```
cresignsys.com
```
You can create:
```
learn
shop
blog
api
mail
```
and so on.

39. Your Hosting Architecture

You could have:
```
cresignsys.com
│
├── www
├── learn
├── shop
├── hosting
├── api
└── blog
```
Each can point to:
```
same VPS
```
or:
```
different servers
```
40. Multiple Domains, One VPS

For example:
```
domain-a.com
        ↓
203.0.113.25

domain-b.com
        ↓
203.0.113.25

domain-c.com
        ↓
203.0.113.25
```
All can reach the same VPS.

Nginx then determines which website should handle the request based largely on the hostname and server configuration.

41. DNS Does Not Choose the Website

This is an important distinction.

DNS determines:
```
domain
 ↓
IP
```
Nginx determines:
```
HTTP Host / TLS hostname
 ↓
website configuration
```
So:
```
DNS
=
Which server?

Nginx
=
Which website on that server?
```
This is simplified but extremely useful.

42. Example

Suppose:
```
shop.cresignsys.com
```
and:
```
learn.cresignsys.com
```
both resolve to:
```
203.0.113.25
```
DNS doesn’t care which WordPress installation should serve the request.

The request reaches Nginx with the hostname.

Nginx can then select:
```
shop
```
or:
```
learn
```
43. Host Header

An HTTP request contains a hostname.

For HTTP/1.1, for example:
```
GET /
Host: learn.cresignsys.com
```
Nginx uses this information when matching server blocks.

44. HTTPS and SNI

For HTTPS, the hostname is also communicated during TLS through:
```
SNI
```
So for HTTPS:
```
TLS SNI
+
HTTP Host
```
both help identify the intended website.

45. DNS Is Before HTTP

Remember:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
Therefore Nginx cannot receive an ordinary web request until DNS resolution and network connectivity have gotten the client to the server.

46. Recursive Resolver Cache

Suppose:
```
Google DNS
```
has:
```
learn.cresignsys.com
 ↓
old IP
```
cached.

Your computer asks Google DNS:
```
What is learn.cresignsys.com?
```
Google DNS may answer from its cache without contacting the authoritative server.

47. Browser Cache

Your browser can also cache DNS information.

So there can be multiple caching layers:
```
Browser
 ↓
Operating system
 ↓
Local router/ISP resolver
 ↓
Recursive DNS cache
```
Exact behavior varies by system and application.

48. Why nslookup Can Be Misleading

If you run:
```
nslookup example.com
```
you are asking the resolver configured for that system.

If that resolver has cached data, you may not be seeing the authoritative server directly.

49. Specify a Resolver

You previously used:
```
nslookup example.com 8.8.8.8
```
This explicitly asks Google’s public resolver.

You can also query another resolver.

For example:
```
nslookup example.com 1.1.1.1
```
50. dig

dig provides more detailed DNS information.

Basic:
```
dig example.com
```
Short answer:
```
dig +short example.com
```
Specific record:
```
dig example.com A
```
51. Query AAAA
```
dig example.com AAAA
```
This checks IPv6 records.

52. Query MX
```
dig example.com MX
```
Useful when diagnosing email delivery.

53. Query TXT
```
dig example.com TXT
```
Useful for verification and email authentication records.

54. Query NS
```
dig example.com NS
```
This shows nameserver information.

55. Query SOA
```
dig example.com SOA
```
This provides zone authority information.

56. dig +trace

One of the most educational DNS commands is:
```
dig +trace example.com
```
It walks through the DNS hierarchy.

Conceptually:
```
Root
 ↓
TLD
 ↓
Authoritative
 ↓
Answer
```
This is extremely useful for learning DNS.

57. What +trace Shows

It can demonstrate:
```
.
 ↓
com.
 ↓
example.com.
 ↓
authoritative server
 ↓
A record
```
This makes the DNS hierarchy visible.

58. Authoritative vs Recursive

This distinction is critical.

Recursive resolver

Finds answers on behalf of clients and caches them.

Authoritative server

Provides authoritative answers for zones it serves.

59. Example

Your computer:
```
Laptop
 ↓
8.8.8.8
```
Google DNS is acting as a recursive resolver.

Then:
```
8.8.8.8
 ↓
authoritative DNS
```
The authoritative server provides the domain’s authoritative record.

60. Who Controls DNS?

This depends on where you delegate your domain.

A domain registrar manages registration.

DNS hosting may be provided by:
```
Registrar
```
or:
```
Dedicated DNS provider
```
or:
```
Cloud provider
```
These are related but separate functions.

61. Registrar

A registrar is where a domain is registered.

For example:
```
cresignsys.com
```
is registered through a domain registrar.

The registrar manages registration-related information and allows you to configure nameserver delegation.

62. Nameserver Delegation

The registrar tells the DNS hierarchy:
```
cresignsys.com
 ↓
these nameservers are authoritative
```
For example:
```
ns1.provider.com
ns2.provider.com
```
63. Nameserver Flow

Conceptually:
```
Registrar
 ↓
delegates domain
 ↓
authoritative nameservers
 ↓
DNS records
```
64. Why Nameservers Matter

Suppose you edit an A record at:
```
DNS Provider A
```
but the domain is actually delegated to:
```
DNS Provider B
```
Your change won’t affect the authoritative DNS for the domain.

This is a common configuration mistake.

65. DNS Diagnostic Question

When a DNS change doesn’t work, first ask:

Which nameservers are authoritative for this domain?

Run:
```
dig example.com NS
```
Then verify you are editing DNS at the correct provider.

66. A Record Example for Your Hosting

Suppose your VPS public IP is:
```
203.0.113.25
```
You could configure:
```
learn.cresignsys.com
A
203.0.113.25
```
Then:
```
learn.cresignsys.com
 ↓
203.0.113.25
```
67. Wildcard DNS

You can also create:
```
*.cresignsys.com
```
as a wildcard record.

For example:
```
*.cresignsys.com
A
203.0.113.25
```
Then many otherwise-unconfigured subdomains can resolve to that IP.

But wildcard DNS does not automatically create the website configuration in Nginx.

68. Wildcard DNS ≠ Wildcard SSL

These are separate:
```
Wildcard DNS
=
DNS resolution
```
```
Wildcard certificate
=
TLS certificate coverage
```
You can have one without the other.

69. Wildcard DNS + Nginx

Suppose:
```
*.cresignsys.com
 ↓
203.0.113.25
```
Then:
```
anything.cresignsys.com
```
may resolve to your VPS.

But Nginx still needs to know what to do with:
```
anything.cresignsys.com
```
70. Wildcard Hosting

A hosting platform could potentially implement:
```
*.cresignsys.com
        ↓
VPS
        ↓
Nginx
        ↓
dynamic website routing
```
But production hosting usually uses explicit domain/site configurations or controlled wildcard routing.

71. DNS and SSL Are Separate

A common mistake is thinking:
```
DNS correct
=
SSL correct
```
No.

You need:
```
DNS
 ↓
correct IP

SSL
 ↓
certificate for correct hostname
```
Both must be correct.

72. DNS and Nginx Are Separate

Similarly:
```
DNS
 ↓
correct IP
```
doesn’t mean:
```
Nginx
 ↓
correct website
```
Nginx needs appropriate configuration.

73. Example Failure

DNS:
```
learn.cresignsys.com
 ↓
correct VPS
```
Nginx:
```
server_name learn.cresignsys.com
```
missing.

Result:
```
request reaches server
 ↓
wrong/default server block
```
DNS is correct, but the website can still be wrong.

74. Example Another Failure

DNS:
```
learn.cresignsys.com
 ↓
old VPS
```
Nginx on the new VPS:
```
correct
```
But users still reach the old VPS.

The Nginx configuration isn’t the problem.

DNS is.

75. DNS Troubleshooting Method

When a domain doesn’t work:
```
1. Check authoritative nameservers
2. Check A record
3. Check AAAA record
4. Check CNAME if used
5. Check TTL
6. Check resolver results
7. Check actual VPS IP
8. Check TCP 80/443
9. Check Nginx
```
76. First Command
```
dig +short example.com
```
Ask:

Does this return the IP I expect?

77. Second Command
```
dig example.com NS
```
Ask:

Are these the nameservers I intended?

78. Third Command
```
dig example.com A
```
Ask:

What IPv4 address is authoritative/returned?

79. Fourth Command
```
dig example.com AAAA
```
Ask:

Is there an IPv6 address?

If you haven’t configured IPv6 correctly, an incorrect AAAA record can cause connection problems for IPv6-capable clients.

80. Fifth Command
```
dig +trace example.com
```
This helps determine where the DNS delegation/lookup path is going wrong.

81. DNS Failure Categories

NXDOMAIN

Means the queried domain name does not exist according to the responding DNS system.

SERVFAIL

Means the resolver could not successfully obtain/validate an answer.

NOERROR with no answer

The name may exist, but the requested record type may not exist.

These distinctions are useful when diagnosing DNS.

82. NXDOMAIN

Example:
```
learn.example.com
```
doesn’t exist.

The resolver can return:
```
NXDOMAIN
```
Meaning approximately:

This name does not exist.

83. SERVFAIL

Can occur due to problems such as:
```
DNSSEC validation failure
authoritative server failure
delegation problems
network/server issues
```
The exact cause requires further investigation.

84. DNSSEC

DNS can also use:

DNSSEC

DNSSEC provides cryptographic validation of DNS data.

Conceptually:
```
DNS
+
digital signatures
=
DNSSEC
```
It helps protect against certain forms of DNS data tampering.

85. DNSSEC Is Different From TLS

TLS:
```
protects application communication
```
DNSSEC:
```
authenticates DNS data
```
They solve different problems.

86. TTL and Caching Again

Suppose:
```
A record:
old IP
TTL:
3600
```
You change:
```
new IP
```
A resolver that already cached the old value can continue using it until its cached TTL expires.

So:
```
change DNS
≠
every device immediately changes
```
87. Why Different Computers Show Different IPs

Suppose:
```
Computer A
 ↓
Resolver A
 ↓
old IP
```
while:
```
Computer B
 ↓
Resolver B
 ↓
new IP
```
Both can temporarily happen during a DNS change.

88. Local Cache

Your own computer can cache DNS results.

Windows can display/clear its DNS cache using:
```
ipconfig /displaydns
```
and:
```
ipconfig /flushdns
```
Use flushing for troubleshooting; it does not change authoritative DNS.

89. DNS Is Distributed

The Internet doesn’t have:
```
one giant DNS server
```
Instead:
```
Root
 ↓
TLD
 ↓
Authoritative servers
 ↓
Recursive resolvers
 ↓
Caches
```
This distributed architecture allows DNS to scale globally.

90. Your Hosting Platform

For every website created on your hosting platform, you ultimately need:
```
Domain
 ↓
DNS
 ↓
VPS IP
 ↓
Nginx server_name
 ↓
Website directory
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Database
```
DNS is the first major external connection to the hosting system.

91. Automated Hosting Workflow

A future CresignSys hosting system could do:
```
Create Website
      ↓
Domain entered
      ↓
DNS record created
      ↓
A record → VPS
      ↓
Nginx configuration
      ↓
Website directory
      ↓
Database
      ↓
WordPress
      ↓
SSL
      ↓
HTTPS
```
This is essentially the foundation of a simplified hosting control panel.

92. The Complete Internet-to-Database Journey

You can now see the entire journey:
```
USER
 │
 ▼
DOMAIN
 │
 ▼
DNS
 │
 ▼
IP ADDRESS
 │
 ▼
ROUTING
 │
 ▼
TCP
 │
 ▼
TLS
 │
 ▼
HTTP
 │
 ▼
NGINX
 │
 ▼
PHP-FPM
 │
 ▼
WORDPRESS
 │
 ▼
MYSQL
 │
 ▼
INNODB
 │
 ▼
BUFFER POOL
 │
 ▼
DISK
```
That is the foundation of your web-hosting infrastructure.

93. The Most Important DNS Commands

Start practicing these:
```
dig +short example.com
```
```
dig example.com A
```
```
dig example.com AAAA
```
```
dig example.com NS
```
```
dig example.com MX
```
```
dig example.com TXT
```
```
dig example.com SOA
```
```
dig +trace example.com
```
94. Windows Commands

Since you also manage your server from Windows:
```
nslookup example.com
```
Specific resolver:
```
nslookup example.com 8.8.8.8
```
IPv4/IPv6 and other details can be queried interactively with nslookup.

95. One Important Difference

Remember:
```
nslookup
=
simple DNS diagnostic
```
while:
```
dig
=
more detailed DNS analysis
```
For serious server administration, learn dig.

96. Lesson 050 Core Model

Memorize:
```
Domain
 ↓
Recursive Resolver
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
DNS Record
 ↓
IP
```
But if cached:
```
Domain
 ↓
Recursive Resolver
 ↓
Cache
 ↓
IP
```
97. DNS Record Cheat Sheet

Record Purpose
A IPv4 address
AAAA IPv6 address
CNAME Alias to another hostname
MX Mail server
TXT Text/verification/authentication data
NS Authoritative nameserver
SOA Zone authority information

98. Three Things to Never Confuse

DNS
```
domain → IP
```
Nginx
```
hostname → website configuration
```
TLS
```
hostname → certificate/security
```
Together:
```
DNS
 ↓
server
 ↓
Nginx
 ↓
TLS
 ↓
website
```
Lesson 050 Complete

Your basic web-hosting architecture is now:
```
                     INTERNET
                         │
                         ▼
                      DOMAIN
                         │
                         ▼
                        DNS
                         │
                         ▼
                    PUBLIC IP
                         │
                         ▼
                    OCI NETWORK
                         │
                         ▼
                       VNIC
                         │
                         ▼
                      UBUNTU
                         │
                         ▼
                      TCP 443
                         │
                         ▼
                        TLS
                         │
                         ▼
                       NGINX
                         │
                         ▼
                     PHP-FPM
                         │
                         ▼
                     WORDPRESS
                         │
                         ▼
                       MYSQL
                         │
                         ▼
                      INNODB
                         │
                         ▼
                        DISK
```
Next Lesson — 051

Linux Process Management — What Actually Runs on Your VPS?

We will go underneath the services and understand:
```
Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Thread
 ↓
CPU
 ↓
RAM
 ↓
systemd
 ↓
service
```
Then we will connect it directly to:
```
nginx
php-fpm
mysqld
sshd
cron
certbot
```
and learn why a service can be installed, enabled, running, listening, or crashed—and why those are all different states.
August 13, 2026
CresignSys Learn — Lesson 049
TLS / HTTPS From the Absolute Basics

We now understand:
```
Browser
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
???
 ↓
HTTP
 ↓
Nginx
```
The missing layer is:

TLS

TLS is what makes ordinary HTTP into secure HTTPS.

1. HTTP vs HTTPS

HTTP:
```
Browser
   ↓
HTTP
   ↓
Server
```
HTTPS:
```
Browser
   ↓
TLS
   ↓
HTTP
   ↓
Server
```
More precisely:
```
HTTP data
   ↓
TLS protection
   ↓
TCP
   ↓
IP
```
2. What Does HTTPS Mean?

HTTPS means:

HTTP Secure

It is HTTP transmitted through a secure TLS connection.

So:
```
HTTPS
=
HTTP
+
TLS
```
3. Why Do We Need TLS?

Imagine sending:
```
Username: admin
Password: secret
```
over an unencrypted connection.

Someone capable of observing the traffic could potentially read the data.

TLS protects the communication against many forms of network interception.

4. TLS Provides Three Major Properties

A useful simplified model is:
```
TLS
│
├── Confidentiality
├── Integrity
└── Authentication
```
5. Confidentiality

Confidentiality means:

Unauthorized observers should not be able to read the protected data.

Conceptually:
```
Browser
   ↓
encrypted data
   ↓
Internet
   ↓
Server
```
An observer sees encrypted traffic rather than the original HTTP contents.

6. Integrity

Integrity means:

The data should not be silently modified without detection.

For example:
```
Browser
 ↓
"Pay ₹100"
 ↓
Internet
 ↓
Server
```
TLS provides mechanisms that allow the receiver to detect tampering with protected records.

7. Authentication

Authentication answers:

Who am I actually communicating with?

When you visit:
```
https://example.com
```
the browser needs confidence that the server is authorized for:
```
example.com
```
This is where certificates enter.

8. Certificate

A TLS certificate is a digitally signed document containing information about an identity and a public key.

Conceptually:
```
Certificate
│
├── Domain identity
├── Public key
├── Validity period
├── Issuer
└── Digital signature
```
9. Example

A certificate might cover:
```
example.com
```
and possibly:
```
www.example.com
```
depending on the certificate’s Subject Alternative Names.

10. Certificate Is Not the Private Key

This distinction is extremely important.

You have:
```
Public key
+
Private key
```
The certificate contains the public key and identity information.

The private key is kept secret on the server.

11. Public Key

A public key can be shared.

Conceptually:
```
Public key
=
safe to distribute
```
The browser can receive it as part of the certificate.

12. Private Key

The private key must remain secret.

Conceptually:
```
Private key
=
server secret
```
If someone obtains the private key, the security of that certificate’s use can be compromised.

13. Public-Key Cryptography

TLS uses asymmetric cryptographic concepts.

You have:
```
Public key
        +
Private key
```
They are mathematically related.

But the private key cannot feasibly be derived from the public key using ordinary practical computation with current cryptographic assumptions.

14. Simple Analogy

Think of:
```
Public key
=
open padlock

Private key
=
key that controls the padlock
```
Anyone can have the padlock.

Only the authorized party should have the private key.

This is only an analogy; TLS cryptography is more sophisticated.

15. Certificate Authority

Who says:

This public key belongs to example.com?

A:

Certificate Authority

or:

CA

does this through digital signatures and certificate issuance.

16. Examples of Certificate Authorities

There are many certificate authorities.

One important one for your hosting setup is:

Let’s Encrypt

Let’s Encrypt provides automated, publicly trusted TLS certificates.

17. Trust Chain

Your browser doesn’t blindly trust every certificate.

Instead, it has a set of trusted root certificates.

Conceptually:
```
Browser
   ↓
Trusted Root CA
   ↓
Intermediate CA
   ↓
Your Website Certificate
```
This is called a:

Certificate Chain

18. Root CA

A root certificate is trusted by the operating system/browser trust store.

Conceptually:
```
Root CA
 ↓
trusted
```
19. Intermediate CA

A root CA often signs an intermediate CA.

Then the intermediate CA issues website certificates.

Conceptually:
```
Root
 ↓
Intermediate
 ↓
example.com
```
This allows a hierarchy of trust.

20. Why Not Have the Root Sign Every Website?

Using intermediates provides separation and operational security.

The root can remain more protected while intermediates handle certificate issuance.

21. Certificate Chain

When your server sends the certificate chain:
```
Server
 ↓
website certificate
 ↓
intermediate certificate
```
the browser can build a path toward a trusted root.

22. Let’s Encrypt

For your hosting platform, the simplified process is:
```
Domain
 ↓
prove control
 ↓
Let's Encrypt
 ↓
certificate issued
 ↓
Nginx configured
 ↓
HTTPS
```
23. Domain Validation

Before issuing a certificate, the CA needs to verify that the requester controls the domain.

One common method is:

HTTP-01 Challenge

The CA asks the server to make a specific resource available.

Conceptually:
```
Let's Encrypt
 ↓
HTTP request
 ↓
http://example.com/.well-known/...
 ↓
your server
```
If the expected challenge is returned, domain control is demonstrated.

24. DNS-01 Challenge

Another method is:

DNS-01

The requester proves control by creating a special DNS TXT record.

Conceptually:
```
Let's Encrypt
 ↓
DNS query
 ↓
TXT record
 ↓
proof of domain control
```
This is especially useful for some wildcard certificate scenarios.

25. HTTP-01 vs DNS-01

HTTP-01
```
Domain
 ↓
HTTP
 ↓
challenge file
```
DNS-01
```
Domain
 ↓
DNS TXT
 ↓
challenge
```
26. Wildcard Certificates

Suppose you want:
```
*.cresignsys.com
```
This can cover subdomains such as:
```
learn.cresignsys.com
shop.cresignsys.com
hosting.cresignsys.com
```
Wildcard certificates generally require DNS-based validation such as DNS-01.

27. One Certificate Per Domain

You can have:
```
example.com
 ↓
certificate A
```
and:
```
shop.example.com
 ↓
certificate B
```
Or one certificate can cover multiple names through SANs.

28. SAN

SAN means:

Subject Alternative Name

A certificate can contain multiple DNS names.

For example:
```
example.com
www.example.com
shop.example.com
```
all could potentially be included in one certificate.

29. Why Your Hosting Platform Needs SSL Automation

Suppose you have:
```
100 websites
```
Manually installing certificates would be tedious.

A hosting platform can automate:
```
Domain created
 ↓
DNS verified
 ↓
Certificate requested
 ↓
Challenge completed
 ↓
Certificate installed
 ↓
Nginx configured
 ↓
HTTPS tested
 ↓
Renewal scheduled
```
This is exactly the type of workflow a hosting control panel manages.

30. TLS Handshake

Now we reach the deeper part.

Before encrypted application data is exchanged, the client and server perform a:

TLS Handshake

The handshake establishes the parameters needed for the secure connection.

31. Simplified TLS Flow

Conceptually:
```
Browser
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   │ Certificate
   ▼
Browser
   │
   │ key establishment
   ▼
Secure keys established
   │
   ▼
Encrypted HTTP
```
This is a simplified conceptual picture.

Modern TLS 1.3 has a more specific handshake structure.

32. ClientHello

The browser begins with information about what it supports.

Conceptually:
```
ClientHello
│
├── TLS versions
├── Cipher suites
├── Random value
├── Extensions
└── SNI
```
33. TLS Version

Modern servers should generally support modern TLS versions.

The major modern version is:

TLS 1.3

TLS 1.2 is also widely deployed.

Old versions such as TLS 1.0 and TLS 1.1 should generally not be enabled on modern public websites.

34. Cipher Suite

A cipher suite describes cryptographic algorithms used by TLS.

You may encounter names such as:
```
TLS_AES_128_GCM_SHA256
```
or:
```
TLS_AES_256_GCM_SHA384
```
These names look complicated because they describe multiple cryptographic components.

35. Don’t Memorize Cipher Names Yet

At this stage, understand:
```
Cipher suite
=
set of cryptographic algorithms used by TLS
```
The important concept is negotiation between client and server.

36. ServerHello

The server selects compatible parameters.

Conceptually:
```
Client
 ↓
supported options
 ↓
Server
 ↓
chosen options
```
37. Certificate

The server sends its certificate chain.

For example:
```
Server
 ↓
example.com certificate
 ↓
intermediate certificate
```
The browser validates the certificate.

38. Certificate Validation

The browser checks things such as:
```
Is it expired?
Is the domain name covered?
Is the signature valid?
Is the issuer trusted?
Is the certificate chain valid?
```
39. Domain Name Validation

Suppose you visit:
```
https://example.com
```
but the certificate is only valid for:
```
otherdomain.com
```
The browser should reject it or display a certificate warning.

40. Why SNI Exists

Imagine one server has:
```
example.com
shop.example.com
learn.example.com
```
all using:
```
IP address:
203.0.113.25
```
How does the server know which certificate the client wants?

The browser sends:

SNI

Server Name Indication.

41. SNI

The browser effectively indicates:
```
I am connecting to:

learn.example.com
```
during the TLS handshake.

Nginx can then select the appropriate server configuration and certificate.

42. One IP, Many HTTPS Websites

This is fundamental to hosting.

You can have:
```
203.0.113.25
│
├── example.com
├── shop.example.com
├── learn.example.com
└── anotherdomain.com
```
All using port:
```
443
```
SNI helps the server determine which hostname the client requested.

43. Nginx Server Blocks

You may have configurations like:
```
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate ...;
    ssl_certificate_key ...;
}
```
and:
```
server {
    listen 443 ssl;
    server_name shop.example.com;

    ssl_certificate ...;
    ssl_certificate_key ...;
}
```
Both can listen on:
```
443
```
because Nginx uses the hostname and connection information to select the appropriate configuration.

44. Private Key

Nginx needs access to the private key.

Conceptually:
```
Nginx
 ├── certificate
 └── private key
```
The private key must have appropriate permissions.

45. Never Publish the Private Key

Do not put:
```
private key
```
inside:
```
public_html
public/
wp-content/
```
It must remain outside publicly served directories.

46. Public vs Private

For a typical certificate:
```
Certificate
=
public information
```
```
Private key
=
secret
```
This distinction is critical.

47. Let’s Encrypt Files

Certbot installations commonly use locations under:
```
/etc/letsencrypt/
```
For example:
```
/etc/letsencrypt/live/example.com/
```
The exact file structure depends on the ACME client and configuration.

48. Common Certificate Files

You may encounter:
```
fullchain.pem
cert.pem
privkey.pem
chain.pem
```
Conceptually:
```
cert.pem
=
website certificate

chain.pem
=
intermediate chain

fullchain.pem
=
certificate + intermediate chain

privkey.pem
=
private key
```
49. Nginx Configuration

A common Nginx configuration looks conceptually like:
```
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
```
The exact configuration generated by your certificate tooling can vary.

50. Why fullchain.pem?

The browser needs to be able to build the certificate chain.

Sending the website certificate plus required intermediate certificate(s) helps the client validate the chain.

51. Certificate Expiration

Certificates have a validity period.

Let’s Encrypt certificates are intentionally short-lived.

This is why:

Automatic Renewal

is essential.

52. Why Short-Lived Certificates?

Short-lived certificates reduce the period during which a compromised or otherwise problematic certificate remains valid.

But the trade-off is:
```
short validity
 ↓
frequent renewal
 ↓
automation required
```
53. Renewal

Your server needs a process that periodically checks whether certificates need renewal.

For example:
```
Certificate
 ↓
approaching renewal window
 ↓
ACME client
 ↓
renew
 ↓
update certificate
 ↓
reload Nginx
```
54. Renewal Failure

If automation fails repeatedly:
```
certificate expires
 ↓
browser warning
 ↓
website HTTPS problem
```
This is why SSL monitoring matters in hosting.

55. Test Certificate

You can use:
```
openssl s_client -connect example.com:443 -servername example.com
```
This gives detailed TLS information.

56. Why -servername?

This option sends SNI.

For a multi-domain server, that matters.

Without SNI, you may inspect the wrong certificate or default server configuration.

57. curl TLS Testing

You can also use:
```
curl -Iv https://example.com
```
This provides useful TLS and HTTP diagnostics.

58. Certificate Inspection

You can inspect a certificate using OpenSSL.

Conceptually:
```
openssl s_client -connect example.com:443 -servername example.com
```
Then inspect the certificate chain and TLS negotiation.

59. TLS and HTTP Separation

This is important:
```
TLS
=
security layer
```
```
HTTP
=
application protocol
```
TLS doesn’t replace HTTP.

It protects HTTP.

60. HTTPS Request

Once TLS is established:
```
Encrypted connection
        ↓
GET /about/
        ↓
Nginx
```
The HTTP request is carried inside the TLS-protected connection.

61. What Does an Observer See?

A network observer may be able to see metadata such as:
```
source IP
destination IP
destination port
traffic timing
traffic size patterns
```
But properly configured TLS prevents them from simply reading the HTTP request and response contents.

TLS does not make all metadata invisible.

62. HTTPS Does Not Hide the IP Address

Suppose:
```
example.com
 ↓
203.0.113.25
```
The network still needs to route traffic to the IP.

So:
```
HTTPS
≠
anonymous
```
It primarily protects the contents and authenticates the endpoint through the TLS system.

63. HTTPS Does Not Protect a Compromised Server

Suppose:
```
WordPress
 ↓
malware
```
TLS can still be functioning perfectly.

TLS protects communication between client and server.

It does not automatically secure the application itself.

64. HTTPS vs Website Security

These are different:
```
TLS security
```
versus:
```
WordPress security
```
You need both.

65. TLS Certificate vs Domain Ownership

A certificate doesn’t mean:

The domain belongs to this company in a legal/business sense.

It means the CA validated control of the domain according to the certificate issuance process and issued a certificate.

This distinction matters.

66. Certificate Warning

If the browser says:
```
Your connection is not private
```
possible causes include:
```
expired certificate
wrong hostname
untrusted issuer
incomplete chain
certificate mismatch
incorrect system time
TLS configuration issue
```
67. Wrong Certificate on Multi-Domain Server

Suppose:
```
example.com
shop.example.com
learn.example.com
```
all share one IP.

But the browser receives:
```
example.com certificate
```
when visiting:
```
shop.example.com
```
Then the hostname doesn’t match.

Possible causes:
```
incorrect SNI handling
wrong Nginx server block
certificate configuration
default server selection
```
68. This Is Why server_name Matters

Nginx:
```
server_name shop.example.com;
```
tells Nginx which hostname this server block handles.

69. HTTP to HTTPS Redirect

Many websites run:
```
HTTP :80
```
and redirect to:
```
HTTPS :443
```
Conceptually:
```
http://example.com
       ↓
301
       ↓
https://example.com
```
70. Why Keep Port 80?

You might ask:

If HTTPS is secure, why use port 80 at all?

Because HTTP can be used to:
```
redirect to HTTPS
perform HTTP-01 ACME validation
serve legacy traffic if intentionally configured
```
Many sites keep port 80 open solely for redirect/validation purposes.

71. Nginx Example

Conceptually:
```
server {
    listen 80;
    server_name example.com;

    return 301 https://$host$request_uri;
}
```
Then HTTPS:
```
server {
    listen 443 ssl;
    server_name example.com;

    ...
}
```
72. What Happens During a Normal HTTPS Visit?

Let’s trace it.

User types:
```
https://learn.cresignsys.com
```
Step 1

DNS:
```
learn.cresignsys.com
 ↓
IP
```
Step 2

TCP:
```
client
 ↓
server:443
```
Step 3

TCP handshake:
```
SYN
SYN-ACK
ACK
```
Step 4

TLS handshake:
```
ClientHello
ServerHello
Certificate
key establishment
```
Step 5

Secure session:
```
encrypted channel
```
Step 6

HTTP:
```
GET /
Host: learn.cresignsys.com
```
Step 7

Nginx:
```
server_name
 ↓
location
 ↓
WordPress/PHP
```
73. The Complete Secure Web Stack

You can now visualize:
```
Browser
   │
   ▼
DNS
   │
   ▼
IP
   │
   ▼
TCP
   │
   ▼
TLS
   │
   ▼
HTTP
   │
   ▼
Nginx
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ▼
MySQL
```
74. Your SSL Automation Architecture

For your CresignSys hosting platform, eventually:
```
New Domain
    ↓
DNS configured
    ↓
Nginx HTTP server
    ↓
ACME challenge
    ↓
Let's Encrypt
    ↓
Certificate
    ↓
Private key
    ↓
Nginx HTTPS configuration
    ↓
nginx -t
    ↓
reload
    ↓
HTTPS test
```
Then:
```
Renewal
 ↓
certificate replacement
 ↓
Nginx reload
```
75. A Very Important Security Rule

Never do this:
```
private key
 ↓
public/
 ↓
Internet
```
Correct:
```
private key
 ↓
restricted filesystem location
 ↓
Nginx
```
76. Another Important Rule

Don’t disable TLS verification just because something isn’t working.

For example, avoid treating:
```
curl -k https://example.com
```
as a real fix.

-k tells curl to skip certificate verification.

It can be useful for controlled diagnostics, but it should not be used to hide a real certificate problem.

77. TLS Troubleshooting

If HTTPS fails:
```
1. DNS correct?
2. TCP 443 reachable?
3. Nginx listening?
4. Correct server_name?
5. Correct certificate?
6. Certificate not expired?
7. Correct private key?
8. Correct chain?
9. TLS configuration valid?
10. Nginx reload successful?
```
78. Useful Commands

Check Nginx
```
sudo nginx -t
```
Check port 443
```
sudo ss -ltnp | grep ':443'
```
Check certificate/TLS
```
openssl s_client -connect example.com:443 -servername example.com
```
Check HTTPS
```
curl -Iv https://example.com
```
Check certificate files
```
sudo ls -la /etc/letsencrypt/live/
```
79. Certificate Renewal Architecture

Think:
```
Certificate
     │
     ▼
Expiration date
     │
     ▼
Renewal process
     │
     ▼
ACME challenge
     │
     ▼
New certificate
     │
     ▼
Nginx reload
     │
     ▼
HTTPS continues
```
A hosting service must monitor this lifecycle.

80. The Most Important Vocabulary

Memorize:
```
TLS
=
Transport Layer Security

HTTPS
=
HTTP over TLS

Certificate
=
signed identity/public-key information

Public key
=
shareable cryptographic key

Private key
=
secret cryptographic key

CA
=
Certificate Authority

SNI
=
Server Name Indication

SAN
=
Subject Alternative Name

ACME
=
protocol used for automated certificate issuance/renewal

Let's Encrypt
=
publicly trusted certificate authority providing automated certificates
```
81. The Three Security Questions

Whenever you think about HTTPS, remember:

Confidentiality
```
Can someone read the data?
```
Integrity
```
Can someone modify the data without detection?
```
Authentication
```
Am I communicating with the intended server/domain?
```
TLS addresses these through cryptographic protocols and certificate-based authentication.

82. One Complete Example

Suppose:
```
shop.cresignsys.com
```
points to:
```
your VPS
```
The user visits:
```
https://shop.cresignsys.com
```
The chain is:
```
DNS
 ↓
VPS public IP
 ↓
TCP 443
 ↓
TLS handshake
 ↓
certificate for shop.cresignsys.com
 ↓
secure session
 ↓
HTTP request
 ↓
Nginx server block
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Every layer has a separate responsibility.

83. What You Have Learned

Your complete understanding is now:
```
DOMAIN
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
NGINX
   ↓
PHP-FPM
   ↓
WORDPRESS
   ↓
MYSQL
   ↓
INNODB
   ↓
BUFFER POOL
   ↓
DISK
```
This is the core architecture behind the type of WordPress hosting system you are building.

Lesson 049 Summary

The key idea:

TCP creates the transport connection; TLS secures it; HTTP carries the web request.

So:
```
TCP
 ↓
TLS
 ↓
HTTP
```
And HTTPS:
```
HTTPS
=
HTTP
+
TLS
```
For your hosting platform, SSL automation is:
```
Domain
 ↓
ACME validation
 ↓
Let's Encrypt
 ↓
Certificate
 ↓
Nginx
 ↓
443
 ↓
HTTPS
```
Next Lesson — 050

DNS Deep Internals — From Domain Name to Your VPS

We will go deeper into:
```
Domain
 ↓
Registrar
 ↓
Nameserver
 ↓
Root DNS
 ↓
TLD DNS
 ↓
Authoritative DNS
 ↓
A / AAAA
 ↓
CNAME
 ↓
MX
 ↓
TXT
 ↓
TTL
 ↓
DNS cache
 ↓
Your VPS
```
Then we will connect it directly to your domains such as:
```
cresignsys.com
learn.cresignsys.com
shop.cresignsys.com
```
and explain exactly why changing DNS does not immediately change what every user sees, how propagation really works, and how to diagnose DNS problems from the command line.
August 13, 2026
CresignSys Learn — Lesson 048
TCP/IP From the Absolute Basics

We now go one level deeper into the network.

You already know:
```
Browser
 ↓
DNS
 ↓
IP
 ↓
Internet
 ↓
VPS
 ↓
Port 443
 ↓
Nginx
```
But what actually happens when your browser connects to:
```
learn.cresignsys.com:443
```
The key technology is:

TCP

1. What Is TCP?

TCP means:

Transmission Control Protocol

TCP provides reliable, ordered communication between applications over an IP network.

Think:
```
Application
     ↓
    TCP
     ↓
     IP
     ↓
 Network
```
2. IP vs TCP

These two solve different problems.

IP

Answers:

Where should this packet go?

TCP

Answers:

How can two applications communicate reliably?

So:
```
IP
=
addressing + routing
```
```
TCP
=
reliable transport
```
3. Simple Example

Suppose:
```
Your computer
IP = A

VPS
IP = B
```
You want:
```
A → B
```
IP provides the addressing.

TCP provides the connection between applications.

4. Port Numbers

Suppose your VPS has:
```
IP:
203.0.113.25
```
and Nginx listens on:
```
443
```
The destination becomes:
```
203.0.113.25:443
```
This identifies the destination network endpoint.

5. TCP Connection

TCP is connection-oriented.

Before normal application data is exchanged, TCP establishes a connection.

The classic process is called:

Three-Way Handshake
```
Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client
  │
  │ ACK
  ▼
Server
```
Then application data can flow.

6. SYN

SYN means:

Synchronize

The client essentially says:

I want to establish a TCP connection.

Conceptually:
```
Client → Server
SYN
```
7. SYN-ACK

The server responds:
```
Server → Client
SYN + ACK
```
Meaning approximately:

I received your connection request, and I also want to establish the connection.

8. ACK

The client responds:
```
Client → Server
ACK
```
Now the TCP connection is established.

9. Complete Handshake
```
Client                         Server
  │                              │
  │ -------- SYN -------------> │
  │                              │
  │ <------ SYN + ACK ---------- │
  │                              │
  │ -------- ACK -------------> │
  │                              │
  │       CONNECTION READY       │
  │                              │
```
10. Why Three Messages?

TCP needs both sides to establish that communication parameters can be synchronized.

It isn’t simply:
```
Client → Hello
Server → Okay
```
TCP establishes state on both endpoints.

11. TCP Is Stateful

TCP maintains connection state.

For example:
```
LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT
TIME-WAIT
CLOSED
```
These states help TCP manage connections correctly.

12. Server Listening

Before your browser connects:
```
Nginx
 ↓
TCP port 443
 ↓
LISTEN
```
Nginx has a listening socket.

You can inspect it:
```
sudo ss -ltnp
```
13. Client Connects

Browser:
```
Client
 ↓
destination:
server-ip:443
```
The operating system sends a TCP SYN.

14. Server Receives SYN

The server’s networking stack receives it.

If:
```
port 443
```
is open and a service is listening:
```
SYN
 ↓
TCP stack
 ↓
Nginx socket
```
The server can respond.

15. What If Port 443 Is Blocked?

Suppose OCI security rules block:
```
TCP 443
```
Then the TCP handshake cannot complete normally.

The request may appear to:
```
timeout
```
rather than reaching Nginx.

16. What If Nothing Is Listening?

Suppose:
```
OCI allows 443
Ubuntu firewall allows 443
```
but:
```
Nginx
 ↓
not listening
```
The behavior may be different from a silent firewall drop; the host can reject the connection with TCP RST.

This distinction is useful during troubleshooting.

17. Timeout vs Refused

A simplified distinction:

Timeout

Often indicates:
```
packet dropped
firewall
routing problem
network problem
```
Connection refused

Often indicates:
```
host reachable
but no service accepting that port
```
These are clues, not absolute diagnoses.

18. TCP Data

Once connected:
```
Client
   ↔
Server
```
data can flow in both directions.

For HTTPS:
```
Browser
   ↔
Nginx
```
19. TCP Segmentation

Applications don’t necessarily send one giant network message.

Large data can be divided into smaller TCP segments.

Conceptually:
```
Application data
 ↓
TCP
 ↓
Segment 1
Segment 2
Segment 3
Segment 4
```
20. Sequence Numbers

TCP uses:

Sequence Numbers

They help TCP track the ordering of transmitted data.

Imagine:
```
Segment A
Segment B
Segment C
```
If they arrive out of order:
```
C
A
B
```
TCP can use sequence information to reconstruct the correct byte stream.

21. TCP Provides an Ordered Byte Stream

Applications generally see:
```
A B C D E F
```
rather than worrying about individual IP packets.

TCP handles much of the ordering and reliability underneath.

22. Acknowledgements

The receiver acknowledges received data.

Conceptually:
```
Sender
  │
  │ data
  ▼
Receiver
  │
  │ ACK
  ▼
Sender
```
The acknowledgement tells the sender what data has been received successfully.

23. Lost Packet

Suppose:
```
Segment 1 ✓
Segment 2 ✗
Segment 3 ✓
```
TCP detects that something is missing through sequence/acknowledgement mechanisms.

It can retransmit the missing data.

24. Retransmission

Conceptually:
```
Sender
 ↓
Segment 2
 ↓
LOST
```
Then:
```
Sender
 ↓
Segment 2 again
 ↓
Receiver
```
This is one reason TCP is called reliable.

25. TCP Is Not Magic

Retransmission has a cost.

If packets are repeatedly lost:
```
packet loss
 ↓
retransmission
 ↓
waiting
 ↓
slower transfer
```
So network quality affects performance.

26. Latency

Latency means delay.

For example:
```
Client → Server
```
might take:
```
20 ms
```
while another server might take:
```
200 ms
```
Latency affects interactive applications.

27. RTT

RTT means:

Round-Trip Time

It measures approximately how long it takes for a signal to travel from one endpoint to the other and back.

Example:
```
Client
 ↓ 20 ms
Server
 ↓ 20 ms
Client
```
RTT ≈:
```
40 ms
```
Actual measurement depends on conditions and tooling.

28. Why RTT Matters for Websites

Suppose a page requires many sequential network interactions.

Higher RTT can increase total waiting time.

Modern browsers and HTTP protocols reduce this through:
```
connection reuse
parallelism
multiplexing
caching
```
but latency still matters.

29. Bandwidth

Bandwidth is different from latency.

Bandwidth is roughly:

How much data can be transferred per unit time.

For example:
```
100 Mbps
1 Gbps
10 Gbps
```
30. Latency vs Bandwidth

Think:
```
Latency
=
How long does it take to get there?

Bandwidth
=
How much can we transfer per second?
```
A connection can have:
```
high bandwidth
+
high latency
```
or:
```
low bandwidth
+
low latency
```
They are different characteristics.

31. Packet Loss

Suppose:
```
100 packets sent
```
and:
```
5 packets lost
```
Packet loss =:
```
5%
```
TCP may retransmit lost data.

But high packet loss can significantly hurt performance.

32. Congestion

Imagine many users send traffic through the same network path.
```
Users
 │
 ├── Traffic
 ├── Traffic
 ├── Traffic
 └── Traffic
        ↓
    Network link
```
If the link becomes congested:
```
queues
 ↓
delay
 ↓
packet loss
 ↓
TCP adaptation
```
33. TCP Congestion Control

TCP has mechanisms that adjust sending behavior based on network conditions.

The broad goal is:

Avoid overwhelming the network.

Modern TCP implementations use sophisticated algorithms.

34. Slow Start

A TCP connection doesn’t normally begin by sending at the maximum possible rate immediately.

It starts cautiously and increases its sending rate as conditions allow.

This is commonly associated with:

Slow Start

35. Why Slow Start?

Imagine a new connection immediately sending enormous amounts of traffic.

If the network path can’t handle it:
```
congestion
 ↓
packet loss
 ↓
retransmission
 ↓
worse congestion
```
Slow start helps discover available capacity.

36. Congestion Window

TCP maintains concepts such as:

Congestion Window (cwnd)

This influences how much unacknowledged data can be in flight.

Simplified:
```
small cwnd
 ↓
careful sending
 ↓
network appears healthy
 ↓
increase
```
37. Receive Window

TCP also has:

Receive Window

This relates to how much data the receiver is currently prepared to accept.

So TCP has to consider both:
```
network capacity
+
receiver capacity
```
38. Flow Control

Flow control prevents a fast sender from overwhelming a slower receiver.

Imagine:
```
Sender
 ↓↓↓↓↓↓↓↓↓
Receiver
```
If the receiver cannot process data quickly enough, TCP’s flow-control mechanisms help regulate transmission.

39. Congestion Control vs Flow Control

Memorize:
```
Flow control
=
protect receiver
```
```
Congestion control
=
protect network
```
They are different problems.

40. TCP Ports

A TCP connection is identified by endpoint information.

Conceptually:
```
Client IP
Client Port
Server IP
Server Port
Protocol
```
The combination is often described as a:

5-tuple

For example:
```
TCP
192.0.2.10:53124
203.0.113.25:443
```
41. Why Client Ports Are Random-Looking

Your browser doesn’t normally use port 443 as its local port.

Instead it may use an ephemeral port such as:
```
53124
```
So:
```
Client
192.0.2.10:53124
        ↓
Server
203.0.113.25:443
```
42. Server Port

The server uses a well-known/service port:
```
443
```
Nginx listens there.

43. Client Ephemeral Port

The operating system chooses an available temporary port:
```
53124
```
This allows many simultaneous connections.

For example:
```
Client:53124 → Server:443
Client:53125 → Server:443
Client:53126 → Server:443
```
44. Multiple Users

Thousands of users can connect to the same:
```
server:443
```
because their source addresses and/or source ports differ.

Conceptually:
```
User A :50001 → Server :443
User B :50002 → Server :443
User C :50003 → Server :443
```
45. TCP Connection State

Your server can have many connections:
```
sudo ss -tan
```
You may see:
```
ESTAB
LISTEN
TIME-WAIT
SYN-SENT
```
46. ESTABLISHED

Means a TCP connection is established.

Example:
```
ESTAB
client:53124
server:443
```
Data can flow.

47. LISTEN

Means a server socket is waiting for incoming connections.

Example:
```
LISTEN
0.0.0.0:443
```
Nginx can accept incoming connections there.

48. SYN-SENT

A client has sent a SYN and is waiting for the response.

Conceptually:
```
Client
 ↓
SYN
 ↓
waiting
```
49. SYN-RECV

The server has received a SYN and is in the process of completing the handshake.

50. TCP Connection Closing

TCP also needs to close connections properly.

A simplified closing sequence involves:
```
FIN
ACK
FIN
ACK
```
The exact sequence depends on which side initiates closure and the connection state.

51. FIN

FIN means approximately:

I have finished sending data.

Conceptually:
```
Client → Server
FIN
```
52. ACK

The other side acknowledges:
```
Server → Client
ACK
```
The remaining direction can then close separately.

This is why TCP is full-duplex.

53. Full-Duplex

TCP allows both sides to send data independently.
```
Client
 ↑     ↓
 │     │
 TCP connection
 │     │
 ↓     ↑
Server
```
54. TIME_WAIT

After a TCP connection closes, one side may enter:

TIME_WAIT

This is normal TCP behavior.

You may see many:
```
TIME-WAIT
```
connections on a busy web server.

55. Why TIME_WAIT Exists

It helps ensure delayed packets from an old connection don’t interfere with a later connection using the same endpoint combination.

It also allows the final connection termination process to complete safely.

56. Don’t Automatically Treat TIME_WAIT as an Error

Seeing:
```
1000 TIME-WAIT
```
doesn’t automatically mean the server is broken.

It can simply indicate many short-lived TCP connections.

57. HTTP/1.1

Traditional HTTP/1.1 can reuse TCP connections through:

Keep-Alive

Instead of:
```
Request
 ↓
TCP connection
 ↓
close

Request
 ↓
new TCP connection
```
the browser can reuse a connection:
```
TCP connection
 ↓
Request 1
 ↓
Request 2
 ↓
Request 3
 ↓
...
```
This reduces connection setup overhead.

58. HTTP/2

HTTP/2 goes further.

It can multiplex multiple streams over a single TCP connection.

Conceptually:
```
One TCP connection
│
├── Stream 1
├── Stream 2
├── Stream 3
└── Stream 4
```
This reduces the need for many separate connections.

59. HTTP/3

HTTP/3 changes the transport layer.

Instead of TCP:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
```
QUIC provides transport features above UDP.

60. TCP vs UDP

TCP:
```
Connection-oriented
Reliable
Ordered
Retransmission
Flow control
Congestion control
```
UDP:
```
Connectionless datagram transport
No built-in TCP-style reliability
No built-in ordering
Lower protocol overhead
```
UDP does not mean “unreliable network” in the broader sense; it means the transport protocol itself does not provide TCP’s reliability mechanisms.

61. Why Does HTTP/3 Use UDP?

QUIC implements modern transport features in user space over UDP.

This allows:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
```
with features such as:
```
encryption
multiplexing
connection migration
reliability
```
62. But Your Current Website May Use TCP

When you see:
```
HTTPS
```
it doesn’t automatically tell you whether the connection uses HTTP/1.1, HTTP/2, or HTTP/3.

For HTTP/1.1 and HTTP/2:
```
HTTP
 ↓
TCP
```
For HTTP/3:
```
HTTP
 ↓
QUIC
 ↓
UDP
```
63. TCP and TLS

For traditional HTTPS:
```
TCP
 ↓
TLS
 ↓
HTTP
```
The order is conceptually:
```
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
64. TCP Handshake Before TLS

For a traditional TCP-based HTTPS connection:
```
TCP handshake
      ↓
TLS handshake
      ↓
HTTP request
```
So there are multiple negotiation stages.

65. Complete HTTPS Connection

Simplified:
```
Browser
   │
   │ TCP SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Browser
   │
   │ ACK
   ▼
TCP established
   │
   ▼
TLS handshake
   │
   ▼
Encrypted connection
   │
   ▼
HTTP request
```
66. Why This Matters

When debugging:
```
HTTPS doesn't work
```
you need to determine:
```
TCP failure?
TLS failure?
HTTP failure?
Application failure?
```
These are different problems.

67. Example: TCP Failure
```
443 blocked
```
Result:
```
TLS never starts
```
because TCP hasn’t been established.

68. Example: TLS Failure

Suppose:
```
TCP 443 ✓
TLS ✗
```
Possible causes:
```
certificate problem
TLS configuration
protocol incompatibility
SNI/configuration issue
```
69. Example: HTTP Failure

Suppose:
```
TCP ✓
TLS ✓
HTTP ✓
```
but response is:
```
500 Internal Server Error
```
Now the network works.

The problem is higher in the application/server stack.

70. Example: WordPress Failure
```
TCP ✓
TLS ✓
HTTP ✓
Nginx ✓
PHP-FPM ✓
WordPress ✗
```
You might get:
```
500
```
or a WordPress-specific error page.

71. TCP Testing

A useful test:
```
nc -vz example.com 443
```
If successful, you know the TCP port is reachable.

But this doesn’t prove:
```
TLS works
HTTP works
WordPress works
```
It only tests the TCP connection at a basic level.

72. curl -v

For deeper HTTPS debugging:
```
curl -v https://example.com/
```
This can show stages of the connection, including:
```
DNS resolution
TCP connection
TLS handshake
HTTP request
HTTP response
```
73. Very Useful Command

Try:
```
curl -Iv https://example.com/
```
This combines:
```
-I
```
headers only, and:
```
-v
```
verbose diagnostics.

74. Local Server Test

On the VPS:
```
curl -I http://127.0.0.1
```
This tests the local web server.

If it works:
```
Nginx is responding locally
```
but external access fails:
```
look at networking/firewall/cloud rules
```
75. Binding Address Matters

Suppose Nginx listens on:
```
127.0.0.1:443
```
Then only local connections can normally reach that socket.

If it listens on:
```
0.0.0.0:443
```
it can accept IPv4 connections on the configured interfaces.

This is a major troubleshooting clue.

76. Check Nginx Listening Address

Run:
```
sudo ss -ltnp | grep ':443'
```
Look at the local address.

For example:
```
0.0.0.0:443
```
versus:
```
127.0.0.1:443
```
They mean very different things.

77. TCP and Your Hosting Platform

When you create a website automatically, your platform needs to make sure:
```
DNS
 ↓
public IP
 ↓
TCP 80/443
 ↓
Nginx
 ↓
website
```
is correctly configured.

78. Hosting Automation

Your future hosting script might perform:
```
Create website
       ↓
Create directory
       ↓
Create Nginx config
       ↓
Enable config
       ↓
Reload Nginx
       ↓
Install SSL
       ↓
Verify port 443
       ↓
Test HTTPS
```
A good automation script should verify each stage.

79. Don’t Assume

For example, after:
```
sudo systemctl reload nginx
```
don’t assume:
```
website works
```
Instead test:
```
sudo nginx -t
sudo ss -ltnp | grep ':443'
curl -I https://example.com
```
80. Network Troubleshooting Tree

If website doesn’t load:
```
DNS?
 │
 ├── NO → fix DNS
 │
 └── YES
       ↓
TCP 443?
 │
 ├── NO → routing/firewall/listener
 │
 └── YES
       ↓
TLS?
 │
 ├── NO → certificate/TLS config
 │
 └── YES
       ↓
HTTP?
 │
 ├── NO → Nginx/application
 │
 └── YES
       ↓
WordPress?
 │
 ├── NO → PHP/database/application
 │
 └── YES → working
```
81. Deep Mental Model

You should now visualize:
```
APPLICATION
    │
    ▼
   HTTP
    │
    ▼
   TLS
    │
    ▼
   TCP
    │
    ▼
    IP
    │
    ▼
 Network Interface
    │
    ▼
   Internet
```
On the receiving side:
```
Internet
   │
   ▼
Network Interface
   │
   ▼
IP
   │
   ▼
TCP
   │
   ▼
TLS
   │
   ▼
HTTP
   │
   ▼
Nginx
```
82. One Critical Principle

Each layer has a different job.
```
DNS
=
name → address

IP
=
routing/addressing

TCP
=
reliable transport

TLS
=
encryption/authentication

HTTP
=
web application protocol

Nginx
=
web server
```
Do not mix them together.

83. The Full CresignSys Hosting Stack

You now have:
```
                    DOMAIN
                       │
                       ▼
                      DNS
                       │
                       ▼
                 PUBLIC IP
                       │
                       ▼
                 INTERNET ROUTING
                       │
                       ▼
                  OCI VCN
                       │
                       ▼
                    SUBNET
                       │
                       ▼
                     VNIC
                       │
                       ▼
                    UBUNTU
                       │
              ┌────────┴────────┐
              ▼                 ▼
           FIREWALL          SERVICES
                                │
                                ▼
                              NGINX
                                │
                               TLS
                                │
                               HTTP
                                │
                           PHP-FPM
                                │
                            WORDPRESS
                                │
                             MySQL
                                │
                             InnoDB
                                │
                              DISK
```
This is becoming your complete server mental model.

84. Commands to Practice

Run these on your Ubuntu VPS.

Network interfaces
```
ip addr
```
Routing
```
ip route
```
Listening ports
```
sudo ss -ltnp
```
All TCP connections
```
sudo ss -tan
```
DNS
```
dig +short yourdomain.com
```
HTTP
```
curl -I http://yourdomain.com
```
HTTPS
```
curl -Iv https://yourdomain.com
```
Firewall
```
sudo ufw status
```
Nginx
```
sudo nginx -t
```
85. What You Should Understand Now

You should be able to explain:

What happens when someone opens your website?
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
```
What happens after Nginx receives a PHP request?
```
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Where does the network stop?
```
Internet
 ↓
VNIC
 ↓
Ubuntu
```
Where does application processing begin?
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
```
Lesson 048 Summary

The essential concepts:
```
TCP
=
reliable transport protocol

SYN
=
request to establish TCP connection

SYN-ACK
=
server response to SYN

ACK
=
acknowledgement

Sequence number
=
helps maintain byte ordering

Retransmission
=
resends missing data

RTT
=
round-trip time

Latency
=
delay

Bandwidth
=
transfer capacity

Flow control
=
protect receiver

Congestion control
=
manage network congestion

Port
=
service endpoint

Socket
=
communication endpoint

LISTEN
=
waiting for connections

ESTABLISHED
=
active TCP connection

TIME_WAIT
=
normal post-connection TCP state
```
The most important flow to memorize:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Next Lesson — 049

TLS/HTTPS From the Absolute Basics

We will go inside the part between TCP and HTTP:
```
TCP
 ↓
TLS
 ↓
HTTPS
```
and learn:
```
What is encryption?
What is a certificate?
What is a private key?
What is a public key?
What is a CA?
What is Let's Encrypt?
What is a certificate chain?
What is TLS handshake?
What is SNI?
Why does Nginx need SSL configuration?
Why does a certificate work for one domain but not another?
```
Then we will connect it directly to your Let’s Encrypt + Nginx + multiple-domain hosting setup.
August 13, 2026
CresignSys Learn — Lesson 047
Linux Networking From the Absolute Basics

We now move underneath Nginx.

So far you understand:
```
Browser
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
But an important question remains:

How does the Internet actually reach your Ubuntu VPS?

The answer involves:
```
Network Interface
IP Address
MAC Address
Subnet
Gateway
Routing
Ports
Sockets
TCP
UDP
Firewall
VNIC
Cloud Security Rules
```
1. Start With the Simplest Idea

A network allows computers to communicate.

For example:
```
Computer A
    │
    │ network
    ▼
Computer B
```
On the Internet:
```
Your Browser
     │
     ▼
Internet
     │
     ▼
Your VPS
```
2. Your VPS Is a Computer

Your Oracle Cloud VM is simply a computer running remotely.

Conceptually:
```
Oracle Cloud VM
│
├── CPU
├── RAM
├── Disk
├── Network interface
└── Ubuntu
```
The network interface connects the VM to the network.

3. Network Interface

A network interface is the component through which the operating system communicates over a network.

On Linux you may see interfaces such as:
```
ens3
eth0
lo
```
The exact name depends on the system.

4. lo

You will commonly see:
```
lo
```
This means:

Loopback

It represents the local machine itself.

Its common IPv4 address is:
```
127.0.0.1
```
5. What Is 127.0.0.1?

When a program connects to:
```
127.0.0.1
```
it is communicating with the same machine.

For example:
```
Nginx
 ↓
127.0.0.1
 ↓
local service
```
No external Internet connection is required.

6. Why This Matters to Your Server

Your server may have:
```
Nginx
PHP-FPM
MySQL
```
all running on the same VM.

They can communicate locally.

For example:
```
WordPress
 ↓
MySQL
```
may use:
```
localhost
```
instead of going through the public Internet.

7. IP Address

An IP address identifies a network endpoint.

Example IPv4:
```
203.0.113.25
```
IPv4 has four numeric sections.

Conceptually:
```
203 . 0 . 113 . 25
```
Each section is an octet.

8. Private vs Public IP

An IP can be:
```
Public
```
or:
```
Private
```
A public IP is reachable through the public Internet subject to routing and firewall rules.

A private IP is intended for private network communication.

9. Private IPv4 Ranges

Common private IPv4 ranges include:
```
10.0.0.0/8

172.16.0.0/12

192.168.0.0/16
```
For example:
```
10.0.0.15
```
is a private address.

10. Your Cloud VM

A cloud VM commonly has a private address inside the cloud network.

It may also have a public IP associated with its networking configuration.

Conceptually:
```
Internet
   ↓
Public IP
   ↓
Cloud networking
   ↓
Private IP
   ↓
Ubuntu VM
```
The exact Oracle Cloud networking configuration determines the details.

11. VNIC

In Oracle Cloud, a VM uses a:

VNIC

Virtual Network Interface Card.

Think of it as the VM’s virtual network adapter.

Conceptually:
```
Oracle Cloud VM
      │
      ▼
     VNIC
      │
      ▼
Virtual Cloud Network
```
12. VCN

Oracle Cloud uses:

VCN — Virtual Cloud Network

It provides the networking environment for your cloud resources.

Conceptually:
```
VCN
│
├── Subnet
├── Route table
├── Security rules
└── Network resources
```
13. Subnet

A subnet is a logical portion of an IP network.

Imagine:
```
VCN
│
└── Subnet
      │
      ├── VM A
      ├── VM B
      └── VM C
```
Each resource gets an IP address appropriate to that subnet.

14. CIDR

You will frequently see something like:
```
10.0.0.0/24
```
This is CIDR notation.

CIDR means:

Classless Inter-Domain Routing

15. Understanding /24

For:
```
10.0.0.0/24
```
the /24 means the first 24 bits represent the network portion.

The remaining 8 bits represent host addresses.

A /24 contains:
```
256 total IPv4 addresses
```
although not every address is necessarily assignable to a host depending on the networking environment.

16. /16

For example:
```
10.0.0.0/16
```
has:
```
65,536 total IPv4 addresses
```
Again, usable host allocation depends on the network platform and reserved addresses.

17. Why CIDR Matters

Suppose your VM has:
```
10.0.0.25
```
and the subnet is:
```
10.0.0.0/24
```
The system knows that:
```
10.0.0.x
```
belongs to the local subnet.

18. Network and Host

For:
```
10.0.0.25/24
```
conceptually:
```
Network:
10.0.0.0

Host:
25
```
The actual binary calculation is what determines this.

19. Binary

Computers ultimately work with bits.

An IPv4 address is:
```
32 bits
```
For example:
```
10.0.0.25
```
is represented internally as four 8-bit values.

20. Why Learn Binary?

You don’t need to convert every address manually.

But understanding binary helps explain:
```
subnets
CIDR
routing
network masks
IP ranges
```
21. Subnet Mask

The /24 corresponds to:
```
255.255.255.0
```
So:
```
10.0.0.25/24
```
can also be represented as:
```
10.0.0.25
255.255.255.0
```
22. Default Gateway

Suppose your VM wants to communicate outside its local subnet.

It needs a route toward the outside network.

This commonly involves a:

Default Gateway

Conceptually:
```
VM
 ↓
Default Gateway
 ↓
Internet
```
23. Routing

Routing answers:

Where should this packet go next?

Imagine:
```
VM
 ↓
Router A
 ↓
Router B
 ↓
Router C
 ↓
Destination
```
Each router makes forwarding decisions.

24. Routing Table

Linux maintains a routing table.

Check it with:
```
ip route
```
You might see something conceptually like:
```
default via 10.0.0.1 dev ens3
10.0.0.0/24 dev ens3
```
The exact output on your VM will differ.

25. Meaning of default

A route such as:
```
default via 10.0.0.1
```
means approximately:

For destinations that don’t match a more specific route, send traffic through this gateway.

26. More Specific Routes Win

Suppose:
```
10.0.0.0/24
```
and:
```
default
```
both exist.

For destination:
```
10.0.0.50
```
the /24 route is more specific.

So Linux uses it instead of the default route.

27. Routing Example

Imagine:
```
Destination:
10.0.0.50
```
Linux checks:
```
Do I have a route for 10.0.0.0/24?
```
Yes.

So:
```
send through local interface
```
28. Internet Destination

Now:
```
Destination:
8.8.8.8
```
If there isn’t a more specific route:
```
8.8.8.8
 ↓
default route
 ↓
gateway
```
29. ip addr

To inspect network interfaces:
```
ip addr
```
or:
```
ip a
```
You’ll see:
```
lo
ens3
```
and IP addresses associated with them.

30. Example

Conceptually:
```
2: ens3:
    inet 10.0.0.25/24
```
This means the interface has:
```
IP:
10.0.0.25

Prefix:
24
```
31. ip link

To inspect interfaces:
```
ip link
```
This shows information about network links.

32. Interface State

You might see:
```
state UP
```
or:
```
state DOWN
```
If the interface is down, networking through that interface won’t work normally.

33. MAC Address

Network interfaces have a:

MAC address

Example format:
```
02:42:ac:11:00:02
```
A MAC address operates at the data-link layer.

It is different from an IP address.

34. IP vs MAC

Think:
```
IP
=
logical network addressing
```
```
MAC
=
link-layer interface address
```
Simplified:
```
IP
 ↓
Where is the destination?

MAC
 ↓
Which local network interface?
```
35. Ethernet

On traditional local networks, devices communicate using Ethernet frames.

Conceptually:
```
Application
 ↓
TCP
 ↓
IP
 ↓
Ethernet
 ↓
Network interface
```
36. Packets vs Frames

A useful distinction:
```
IP
=
packet
```
```
Ethernet
=
frame
```
The terminology changes by networking layer.

37. ARP

For IPv4 local networks, a system may need to discover:

Which MAC address corresponds to this local IP?

This involves:

ARP

Address Resolution Protocol.

Conceptually:
```
IP address
 ↓
ARP
 ↓
MAC address
```
38. Example

Suppose your machine needs to communicate with:
```
10.0.0.1
```
It may ask:
```
Who has 10.0.0.1?
```
The device using that IP can respond with its MAC address.

39. Cloud Networking Is More Abstract

In Oracle Cloud, you don’t manually manage physical Ethernet switches.

OCI provides virtualized networking.

So you should think:
```
Physical infrastructure
       ↓
OCI virtualization
       ↓
VNIC
       ↓
VCN
       ↓
Subnet
       ↓
VM
```
40. Port

An IP address identifies a network endpoint.

A:

Port

identifies a service endpoint on that host.

For example:
```
203.0.113.25:443
```
means:
```
IP:
203.0.113.25

Port:
443
```
41. Why Ports Exist

One server can run many services.

For example:
```
Server
│
├── SSH :22
├── HTTP :80
├── HTTPS :443
├── MySQL :3306
└── Other services
```
The port tells the operating system which application should receive the connection.

42. Port 22

Usually:
```
22
=
SSH
```
You use SSH to administer your server.

43. Port 80

Usually:
```
80
=
HTTP
```
Your web server listens here for ordinary HTTP traffic.

44. Port 443

Usually:
```
443
=
HTTPS
```
Your HTTPS websites normally use this port.

45. Port 3306

Conventionally:
```
3306
=
MySQL
```
But MySQL can be configured to use another port.

For security, a database usually should not be exposed publicly unless there is a specific reason and appropriate controls.

46. Socket

A socket is an endpoint for network communication.

Conceptually:
```
IP + Port + Protocol
```
identifies a network communication endpoint.

For example:
```
10.0.0.25:443
```
47. Server Listening

When Nginx is configured for HTTPS:
```
Nginx
 ↓
listen
 ↓
443
```
It opens a listening socket.

Conceptually:
```
0.0.0.0:443
```
means listening on port 443 on all suitable IPv4 interfaces.

48. ss

A very useful Linux networking command is:
```
ss -tulpn
```
It can show listening TCP/UDP sockets and associated processes, subject to permissions.

49. Example

You may see:
```
LISTEN
0.0.0.0:22
```
meaning SSH is listening on IPv4 port 22.

And:
```
LISTEN
0.0.0.0:80
```
meaning something such as Nginx is listening on port 80.

50. Check Web Ports

You can use:
```
sudo ss -ltnp
```
This focuses on TCP listening sockets.

Look for:
```
:80
:443
```
51. If Nginx Is Running But Port 443 Is Missing

Suppose:
```
systemctl status nginx
```
says:
```
active (running)
```
but:
```
sudo ss -ltnp
```
doesn’t show:
```
:443
```
Then HTTPS may not actually be configured/listening.

This illustrates:

Service running ≠ desired port listening.

52. Firewall

Now we reach another major layer.

A firewall controls network traffic according to rules.

Conceptually:
```
Internet
   ↓
Firewall
   ↓
Server
```
53. Firewall Rule

A firewall might allow:
```
TCP 22
TCP 80
TCP 443
```
and block:
```
TCP 3306
```
from the public Internet.

54. Why Multiple Firewall Layers Exist in Cloud Hosting

Your traffic may encounter several security boundaries.

Conceptually:
```
Internet
 ↓
OCI network security
 ↓
VM network
 ↓
Ubuntu firewall
 ↓
Nginx
```
So opening a port in only one layer may not be enough.

55. Oracle Cloud Security Rules

OCI networking can use security controls such as:
```
Security Lists
```
and:
```
Network Security Groups
```
These determine which traffic can reach resources according to the configured rules.

The exact setup depends on your VCN/subnet design.

56. Example HTTPS Rule

You might configure an inbound rule allowing:
```
Protocol:
TCP

Destination port:
443

Source:
0.0.0.0/0
```
Conceptually:
```
Internet
 ↓
TCP 443
 ↓
allowed
 ↓
VM
```
57. What Does 0.0.0.0/0 Mean?

It means:
```
all IPv4 addresses
```
So:
```
Source = 0.0.0.0/0
```
means the rule can apply to traffic originating from anywhere on IPv4, subject to the rest of the rule.

58. Why SSH Should Be Treated Differently

A common rule:
```
TCP 22
Source: 0.0.0.0/0
```
allows SSH from anywhere on the Internet.

That may be convenient, but it increases exposure.

A stronger approach is to restrict SSH to trusted source IPs or use other controlled access mechanisms where practical.

59. Web Ports Are Different

For a public website:
```
80
443
```
normally need to be reachable by Internet users.

So:
```
TCP 443
Source:
Internet
```
is normal for a public HTTPS website.

60. MySQL Should Usually Stay Private

For a single-server WordPress installation:
```
Internet
     X
     ↓
MySQL :3306
```
Instead:
```
WordPress
 ↓
localhost
 ↓
MySQL
```
There is usually no reason for the public Internet to connect directly to MySQL.

61. Network Exposure

Think about every listening service:
```
SSH
HTTP
HTTPS
MySQL
PHP-FPM
```
Ask:

Does this service actually need to be reachable from the Internet?

Usually:
```
HTTP → yes
HTTPS → yes
SSH → controlled access
MySQL → no
PHP-FPM → no
```
62. PHP-FPM Exposure

If PHP-FPM uses:
```
/run/php/php8.3-fpm.sock
```
it isn’t exposed as a TCP Internet service.

That’s good.

If PHP-FPM were listening on a public interface unnecessarily, that would create additional exposure.

63. Localhost Binding

A service can sometimes be bound to:
```
127.0.0.1
```
rather than:
```
0.0.0.0
```
This means it only accepts local connections.

For example:
```
127.0.0.1:9000
```
is not directly reachable from remote machines through the normal network path.

64. 0.0.0.0

When a service listens on:
```
0.0.0.0:80
```
it generally means it is listening on all IPv4 interfaces on port 80.

That can include the public interface.

65. 127.0.0.1

When a service listens on:
```
127.0.0.1:9000
```
it is restricted to local IPv4 connections.

This is an important security concept.

66. IPv6

Not all Internet traffic uses IPv4.

There is also:

IPv6

An IPv6 address might look like:
```
2001:db8::1234
```
IPv6 addresses are 128 bits.

67. Why IPv6 Matters

A server may have:
```
IPv4
+
IPv6
```
If DNS publishes both:
```
A record
AAAA record
```
some clients may connect using IPv6.

68. A Record

DNS:
```
A
```
maps a hostname to an IPv4 address.

Example conceptually:
```
example.com
 ↓
A
 ↓
203.0.113.25
```
69. AAAA Record

DNS:
```
AAAA
```
maps a hostname to an IPv6 address.

Conceptually:
```
example.com
 ↓
AAAA
 ↓
2001:db8::1234
```
70. A Common IPv6 Mistake

Suppose:
```
A
 ↓
correct IPv4
```
but:
```
AAAA
 ↓
incorrect IPv6
```
Some users may experience failures even though IPv4 works correctly.

This is why IPv6 configuration should be deliberate.

71. DNS vs Networking

This distinction is extremely important.

DNS answers:

What IP address corresponds to this hostname?

Networking answers:

Can I actually reach that IP and service?

So:
```
DNS working
```
does not guarantee:
```
website working
```
72. Example

Suppose:
```
example.com
 ↓
203.0.113.25
```
DNS is correct.

But:
```
TCP 443
 ↓
blocked
```
The website still won’t load.

73. Another Example

Suppose:
```
TCP 443
 ↓
allowed
```
but:
```
Nginx
 ↓
not listening
```
Still no working HTTPS website.

74. Another Example

Suppose:
```
Nginx
 ↓
443 listening
```
but:
```
TLS certificate/configuration
 ↓
broken
```
HTTPS can still fail.

75. Another Example

Suppose:
```
HTTPS
 ↓
Nginx
 ↓
PHP-FPM
 ↓
broken
```
The browser may receive:
```
502
```
So each layer must work.

76. Full Connectivity Chain

For:
```
https://example.com
```
you can think:
```
1. DNS
2. IP routing
3. Cloud security rules
4. Ubuntu networking/firewall
5. TCP 443
6. Nginx listening
7. TLS
8. HTTP
9. Application
```
77. Diagnostic Tool: ping

You may know:
```
ping example.com
```
It tests ICMP reachability, not TCP/HTTPS specifically.

A server can block ICMP and still serve HTTPS perfectly.

Therefore:

Ping failure does not automatically mean the website is down.

78. curl

For web testing, curl is much more useful.

Example:
```
curl -I https://example.com
```
This asks for HTTP headers.

You might receive:
```
HTTP/2 200
```
or:
```
HTTP/2 301
```
or:
```
HTTP/2 502
```
79. HTTP Status Codes

Some important ones:
```
200
=
Success

301
=
Permanent redirect

302
=
Temporary redirect

403
=
Forbidden

404
=
Not found

500
=
Application/server error

502
=
Bad gateway

503
=
Service unavailable
```
80. Test HTTP
```
curl -I http://example.com
```
Test HTTPS:
```
curl -I https://example.com
```
This lets you test from the server or another machine without relying on the browser UI.

81. Test DNS
```
dig example.com
```
or:
```
nslookup example.com
```
You previously used:
```
nslookup domain 8.8.8.8
```
This checks DNS resolution through Google’s DNS resolver.

82. Test Port Connectivity

From another machine:
```
nc -vz example.com 443
```
This can test whether TCP port 443 is reachable.

Alternatively:
```
nc -vz example.com 80
```
83. ss vs nc

Remember:
```
ss
=
what is listening locally?
```
```
nc
=
can I connect to this remote port?
```
So:
```
Local diagnosis
 ↓
ss
```
and:
```
Remote connectivity
 ↓
nc
```
84. curl vs nc

nc tests TCP connectivity.

curl goes further and tests the HTTP protocol.

So:
```
nc
=
Can I establish TCP?

curl
=
Can I communicate using HTTP/HTTPS?
```
85. A Practical Website Diagnostic

Suppose:
```
https://example.com
```
doesn’t load.

Use this order:
```
DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL
```
86. Step 1 — DNS
```
dig +short example.com
```
Confirm the expected IP.

87. Step 2 — Local Port

On the VPS:
```
sudo ss -ltnp | grep ':443'
```
Confirm something is listening.

88. Step 3 — Local HTTP Test

From the server:
```
curl -I https://example.com
```
If this works locally but not externally, suspect:
```
cloud firewall
routing
security rules
public IP
DNS
```
89. Step 4 — Nginx
```
sudo systemctl status nginx
```
Then:
```
sudo nginx -t
```
90. Step 5 — Logs
```
sudo tail -f /var/log/nginx/error.log
```
Then make a request.

91. Step 6 — PHP-FPM
```
systemctl status php8.3-fpm
```
Replace the version appropriately.

92. Step 7 — MySQL
```
sudo systemctl status mysql
```
Then verify database connectivity if necessary.

93. This Is Layered Troubleshooting

Never immediately change five configuration files.

Instead:
```
Question
 ↓
Test
 ↓
Evidence
 ↓
Next layer
```
For example:
```
Does DNS resolve?
     ↓
YES
     ↓
Does TCP 443 connect?
     ↓
YES
     ↓
Does TLS work?
     ↓
YES
     ↓
Does Nginx respond?
     ↓
YES
     ↓
Does PHP work?
```
This prevents random troubleshooting.

94. Oracle Cloud Architecture

Your environment can be visualized as:
```
                         INTERNET
                            │
                            ▼
                     Public IP / DNS
                            │
                            ▼
                    Oracle Cloud VCN
                            │
                            ▼
                         Subnet
                            │
                            ▼
                          VNIC
                            │
                            ▼
                      Ubuntu VM
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
             SSH           Nginx        Other
             :22           :80/:443     services
                            │
                            ▼
                       PHP-FPM
                            │
                            ▼
                         MySQL
```
The actual OCI topology can be more detailed, but this is the foundational model.

95. Cloud Security Layer

Think:
```
Internet
 ↓
OCI security rules
 ↓
VNIC
 ↓
Ubuntu
 ↓
local firewall
 ↓
service
```
A connection can be blocked before it reaches Nginx.

96. Ubuntu Firewall

Ubuntu systems may use:

UFW

Uncomplicated Firewall.

Check:
```
sudo ufw status
```
You might see rules such as:
```
22/tcp
80/tcp
443/tcp
```
97. Important: UFW May Not Be Your Only Firewall

Cloud security rules and UFW are separate layers.

For example:
```
OCI allows 443
```
but:
```
UFW blocks 443
```
The connection can still fail.

Likewise:
```
UFW allows 443
```
but:
```
OCI blocks 443
```
It can still fail.

98. Two-Gate Model

Think:
```
Internet
   ↓
[ OCI security ]
   ↓
[ Ubuntu firewall ]
   ↓
[ Nginx ]
```
Traffic must pass all applicable controls.

99. Why This Explains Many Hosting Problems

Suppose you install Nginx correctly.
```
Nginx ✓
```
But forget cloud ingress:
```
OCI security ✗
```
Result:
```
Website inaccessible
```
You might incorrectly think:

Nginx is broken.

It isn’t.

The packet never reached it.

100. Another Example

Suppose:
```
OCI ✓
UFW ✓
Nginx ✗
```
Then:
```
TCP connection
 ↓
Nginx unavailable
```
The service layer is the problem.

101. Another Example

Suppose:
```
OCI ✓
UFW ✓
Nginx ✓
PHP-FPM ✗
```
Then:
```
Static files
 ↓
may work

PHP
 ↓
502/error
```
102. Another Example

Suppose:
```
Everything above works
 ↓
MySQL ✗
```
Then:
```
WordPress
 ↓
database error
```
103. The Layer Model

You should now start thinking like a server administrator:
```
Layer 1
DNS

Layer 2
Network routing

Layer 3
Cloud security

Layer 4
TCP/UDP

Layer 5
Ubuntu firewall

Layer 6
Nginx

Layer 7
TLS/HTTP

Layer 8
PHP-FPM

Layer 9
WordPress

Layer 10
MySQL
```
This is a simplified operational model, not a strict OSI-layer mapping.

104. Important Commands

Start memorizing these:

Network interfaces
```
ip addr
```
Routes
```
ip route
```
Listening services
```
sudo ss -ltnp
```
DNS
```
dig example.com
```
HTTP test
```
curl -I https://example.com
```
Firewall
```
sudo ufw status
```
Nginx
```
sudo systemctl status nginx
```
Nginx configuration
```
sudo nginx -t
```
105. One Powerful Mental Model

When a user says:

“My website is not opening.”

Don’t immediately think:
```
WordPress problem
```
Think:
```
                    Website unavailable
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
            DNS          Network       Application
             │             │             │
             ▼             ▼             ▼
          IP correct?    Port 443?     Nginx?
                                       PHP?
                                       WordPress?
                                       MySQL?
```
Then test each layer.

106. The Full Journey

A user types:
```
https://learn.cresignsys.com
```
The request travels conceptually:
```
Browser
   │
   ▼
DNS Resolver
   │
   ▼
DNS authoritative infrastructure
   │
   ▼
IP address
   │
   ▼
Internet routers
   │
   ▼
OCI network
   │
   ▼
VCN
   │
   ▼
Subnet
   │
   ▼
VNIC
   │
   ▼
Ubuntu
   │
   ▼
TCP :443
   │
   ▼
Nginx
   │
   ▼
TLS
   │
   ▼
HTTP
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ▼
MySQL
```
107. What You Have Learned So Far

Your learning path has now reached:
```
BASIC COMPUTER
      ↓
Linux
      ↓
Filesystem
      ↓
Permissions
      ↓
Networking
      ↓
DNS
      ↓
TCP/IP
      ↓
TLS
      ↓
HTTP
      ↓
Nginx
      ↓
PHP-FPM
      ↓
WordPress
      ↓
MySQL
      ↓
InnoDB
```
This is the foundation of your web-hosting server.

108. Next Level

The next major topic is:

TCP/IP in Depth

We have used TCP repeatedly, but haven’t yet studied what TCP actually does.

We will go deeper into:
```
TCP
│
├── Connection
├── SYN
├── SYN-ACK
├── ACK
├── Sequence numbers
├── Acknowledgements
├── Retransmission
├── Flow control
├── Congestion control
├── Connection termination
└── TIME_WAIT
```
Then:
```
TCP
 ↓
443
 ↓
TLS
 ↓
HTTP
```
will become completely understandable.

Lesson 047 Summary

The most important concepts:
```
VNIC
=
virtual network interface

VCN
=
virtual cloud network

Subnet
=
logical IP network segment

Gateway
=
next-hop router for traffic

Routing table
=
rules determining where packets go

IP
=
network-layer addressing

MAC
=
link-layer addressing

Port
=
service endpoint

Socket
=
communication endpoint

Firewall
=
traffic filtering

UFW
=
Ubuntu firewall management tool

A record
=
hostname → IPv4

AAAA record
=
hostname → IPv6
```
And the most important troubleshooting chain is:
```
DNS
 ↓
IP
 ↓
Route
 ↓
Cloud security
 ↓
TCP port
 ↓
Ubuntu firewall
 ↓
Nginx
 ↓
TLS
 ↓
HTTP
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
That chain is the foundation for diagnosing almost every web-hosting problem.
August 13, 2026
CresignSys Learn — Lesson 046
MySQL Deep Internals — From SQL Query to Disk

We now go one level deeper than ordinary MySQL administration.

So far:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Today:
```
WordPress
 ↓
SQL
 ↓
MySQL
 ↓
Query processing
 ↓
InnoDB
 ↓
RAM
 ↓
Disk
```
The goal is to understand what actually happens inside MySQL when WordPress asks for data.

1. Start With One Simple Question

Suppose WordPress asks:
```
SELECT *
FROM wp_posts
WHERE ID = 100;
```
What happens?

It does not simply mean:
```
MySQL → open file → find row
```
There are several internal stages.

2. The Basic Pipeline

Conceptually:
```
SQL Query
   ↓
Connection
   ↓
Parser
   ↓
Optimizer
   ↓
Execution
   ↓
Storage Engine
   ↓
InnoDB
   ↓
Buffer Pool / Disk
   ↓
Result
```
Let’s examine every layer.

3. Step 1 — Connection

PHP needs to communicate with MySQL.
```
PHP Worker
     ↓
MySQL connection
     ↓
MySQL Server
```
The connection contains information such as:
```
username
password
database
host
port/socket
```
4. Step 2 — SQL Arrives

WordPress sends a query such as:
```
SELECT ID, post_title
FROM wp_posts
WHERE ID = 100;
```
MySQL receives this query.

5. Step 3 — Parser

MySQL first parses the SQL.

It identifies:
```
SELECT
columns
FROM
table
WHERE
condition
```
Conceptually:
```
SQL text
   ↓
Parser
   ↓
understood query structure
```
6. Syntax Error

If the SQL is invalid:
```
SELEC *
FROM wp_posts;
```
MySQL can reject it because:
```
SELEC
```
is not valid SQL syntax.

The parser is one of the layers involved in identifying this.

7. Step 4 — Query Optimizer

Suppose the query is valid.

MySQL now needs to determine an efficient way to execute it.

This is the job of the:

Query Optimizer

8. Why Do We Need an Optimizer?

Suppose a table contains:
```
1,000,000 rows
```
MySQL has multiple possible strategies.

Strategy A

Read every row:
```
row 1
row 2
row 3
...
row 1,000,000
```
Strategy B

Use an index:
```
ID = 100
 ↓
index
 ↓
row 100
```
The second can be dramatically faster.

9. Query Plan

The optimizer creates a plan for executing the query.

You can inspect a query plan with:
```
EXPLAIN
```
Example:
```
EXPLAIN
SELECT *
FROM wp_posts
WHERE ID = 100;
```
10. EXPLAIN

EXPLAIN is one of the most important tools for database performance analysis.

It can show information such as:
```
table
type
possible_keys
key
rows
filtered
Extra
```
The exact output depends on MySQL version and query.

11. The Key Question

When examining:
```
EXPLAIN SELECT ...
```
one important question is:

Is MySQL using an appropriate index?

12. What Is an Index?

Imagine a library with:
```
1,000,000 books
```
and you want:
```
Book ID 783421
```
Without an index, you might search through many books.

With an index:
```
783421
  ↓
location
  ↓
book
```
A database index provides a similar lookup structure.

13. Index Example

Suppose:
```
wp_posts
```
has:
```
ID
post_title
post_content
post_date
```
and ID is indexed.

Then:
```
WHERE ID = 100
```
can efficiently locate the record.

14. Primary Key

A primary key is normally indexed.

For example:
```
wp_posts
   ↓
ID
```
The ID uniquely identifies a post row.

15. Why Indexes Matter

Suppose:
```
1,000 rows
```
A full scan might be acceptable.

But:
```
10 million rows
```
makes inefficient scanning much more expensive.

Indexes can reduce the amount of data MySQL needs to inspect.

16. But Indexes Have a Cost

Indexes consume:
```
Disk
RAM
CPU
write/update resources
```
When a row changes, relevant indexes may also need updating.

Therefore:

An index is an optimization, not free storage.

17. WordPress and Indexes

WordPress tables contain indexes designed around common access patterns.

You can inspect them using:
```
SHOW INDEX FROM wp_posts;
```
This shows index information for the table.

18. Storage Engine

After the optimizer determines a plan, MySQL relies on a storage engine.

For modern WordPress installations, the important engine is:

InnoDB

19. InnoDB

InnoDB is the storage engine responsible for storing and retrieving table data and indexes.

Conceptually:
```
MySQL
 ↓
InnoDB
 ↓
tables + indexes
```
20. Why InnoDB Matters

InnoDB provides major database capabilities including:
```
Transactions
Crash recovery
Row-level locking
Indexes
Buffer pool
Redo logging
Undo information
```
These are fundamental to reliable database operation.

21. InnoDB Does Not Read Every Byte From Disk

This is one of the most important performance concepts.

MySQL tries to keep frequently needed data in RAM.

The main mechanism is:

InnoDB Buffer Pool

22. Buffer Pool

Think of the buffer pool as:
```
RAM
 ↓
frequently used database pages
```
Instead of repeatedly reading from disk:
```
Disk → RAM → query
```
MySQL can often use:
```
RAM → query
```
which is much faster.

23. Simple Analogy

Imagine your desk and a warehouse.
```
Desk
=
RAM
```
```
Warehouse
=
Disk
```
If you repeatedly need the same document, you keep it on your desk.

You don’t walk to the warehouse every time.

The buffer pool works somewhat like the desk.

24. Buffer Pool Flow

Conceptually:
```
SQL Query
   ↓
InnoDB
   ↓
Buffer Pool
   │
   ├── Data already in RAM?
   │       ↓
   │      YES
   │       ↓
   │    use it
   │
   └── NO
           ↓
         Disk
           ↓
        load page
           ↓
       Buffer Pool
```
25. Cache Hit

If the required page is already in memory:
```
Buffer Pool
 ↓
FOUND
```
This is much faster than disk access.

26. Cache Miss

If it isn’t:
```
Buffer Pool
 ↓
NOT FOUND
 ↓
Disk read
 ↓
Memory
```
This introduces additional I/O latency.

27. Why RAM Matters

For a WordPress server:
```
More useful RAM
 ↓
larger useful caches
 ↓
fewer disk reads
 ↓
potentially better performance
```
But RAM isn’t the only performance factor.

CPU, storage, queries, indexes, PHP-FPM, and application behavior all matter.

28. SSD vs HDD

Storage speed also matters.

Traditional HDD:
```
mechanical movement
 ↓
slower random access
```
SSD/NVMe:
```
electronic flash storage
 ↓
much faster random access
```
Modern VPS infrastructure commonly uses SSD/NVMe-backed storage, but the exact storage architecture depends on the provider.

29. Database Pages

InnoDB doesn’t think primarily in terms of:
```
one row at a time
```
It organizes data into fixed-size pages.

A common InnoDB page size is:
```
16 KB
```
unless configured differently.

30. Why Pages?

Suppose you need one row.

The database can load the relevant page containing that row into memory.

Conceptually:
```
Disk
│
├── Page
├── Page
├── Page
└── Page
```
The buffer pool stores these pages.

31. Page Flow
```
Disk
 ↓
InnoDB page
 ↓
Buffer pool
 ↓
SQL operation
```
When a page changes:
```
Application
 ↓
modify page in memory
 ↓
eventually persist changes
```
The details involve InnoDB’s logging and flushing mechanisms.

32. Dirty Page

Suppose a page is loaded into memory.

WordPress changes some data.

The in-memory page is modified.

It is now called a:

Dirty page

Conceptually:
```
Clean page
 ↓
modify
 ↓
Dirty page
```
33. Why Not Immediately Write Everything to Disk?

Constantly writing every tiny modification directly to disk could be inefficient.

Instead, InnoDB uses buffering and logging mechanisms to balance performance and durability.

34. Redo Log

One critical component is the:

Redo Log

Its purpose is related to durability and crash recovery.

Conceptually:
```
Change
 ↓
Redo information
 ↓
persistent log
```
If a crash occurs, InnoDB can use redo information during recovery.

35. Simple Example

Suppose:
```
Post title:
Hello
```
changes to:
```
Hello World
```
InnoDB updates internal structures and records appropriate redo information.

If the system crashes before every modified data page reaches its final disk location, recovery can use the redo log to help restore committed changes.

36. Undo Information

InnoDB also maintains undo information.

Undo supports operations such as:
```
rollback
consistent reads
transaction processing
```
Conceptually:
```
Current data
+
history/undo information
```
37. Redo vs Undo

Remember:
```
REDO
=
help recover/reapply committed changes after failure

UNDO
=
help roll back changes / provide older versions for transactional consistency
```
The exact internal mechanics are more sophisticated, but this mental model is useful.

38. Transaction Example

Suppose an application performs:
```
Operation 1
Operation 2
Operation 3
```
inside a transaction.

Then:
```
COMMIT
```
means the transaction is finalized.

If it needs to be cancelled:
```
ROLLBACK
```
can reverse its changes where transaction semantics permit.

39. WordPress Doesn’t Usually Mean One SQL Query

A WordPress page request can trigger many database queries.

For example:
```
Request
 ↓
WordPress bootstrap
 ↓
settings queries
 ↓
plugin queries
 ↓
theme queries
 ↓
post query
 ↓
metadata queries
 ↓
taxonomy queries
 ↓
...
```
Therefore page performance can depend heavily on database behavior.

40. Plugin Effect

Suppose you install:
```
Plugin A
Plugin B
Plugin C
Plugin D
```
A page request might cause more database work.

Conceptually:
```
No plugins
 ↓
fewer queries

Many plugins
 ↓
potentially more queries
```
But the number of queries alone isn’t enough to judge performance; query complexity and execution time matter too.

41. Query Count vs Query Time

Imagine:
```
100 queries × 1 ms
=
100 ms
```
versus:
```
5 queries × 500 ms
=
2500 ms
```
The second can be much slower despite fewer queries.

42. Slow Query

A slow query might be caused by:
```
Missing index
Poor query design
Large dataset
Bad join strategy
Heavy sorting
Large result set
Resource contention
```
43. EXPLAIN

Suppose:
```
SELECT *
FROM wp_posts
WHERE post_status = 'publish';
```
You can examine:
```
EXPLAIN
SELECT *
FROM wp_posts
WHERE post_status = 'publish';
```
The plan can help determine whether MySQL scans too much data.

44. Full Table Scan

A full table scan means MySQL examines a large portion or all of the table.

Conceptually:
```
wp_posts
 ↓
row 1
row 2
row 3
...
row 1,000,000
```
This isn’t always bad.

For some queries, scanning is the most efficient strategy.

45. Don’t Fear “ALL” Automatically

When reading EXPLAIN, seeing:
```
type = ALL
```
often indicates a full scan.

But whether it is actually a problem depends on:
```
table size
query purpose
rows examined
result size
alternative indexes
```
A full scan of 10 rows isn’t a crisis.

A full scan of 100 million rows may be very different.

46. rows

The rows estimate in EXPLAIN gives an indication of how many rows MySQL expects to examine.

Lower isn’t automatically better in every circumstance, but excessive row examination is often a performance warning.

47. Index Selectivity

An index is especially useful when it can narrow the search significantly.

Imagine:
```
1,000,000 rows
```
and an indexed field identifies only:
```
1 row
```
Very selective.

But if an indexed field has only:
```
2 possible values
```
such as:
```
yes/no
```
it may be less useful depending on the query and data distribution.

48. Composite Index

An index can contain multiple columns.

Example:
```
INDEX (A, B)
```
This is a:

Composite index

The order matters.
```
(A, B)
```
is not equivalent to:
```
(B, A)
```
for all query patterns.

49. Why Index Order Matters

Suppose:
```
INDEX (country, city)
```
This is especially useful for queries that start with:
```
country
```
and then potentially use:
```
city
```
The exact optimizer behavior depends on the query and statistics.

50. Don’t Add Random Indexes

A common beginner mistake is:

“The database is slow, so I’ll add indexes everywhere.”

That can make writes more expensive and increase storage usage.

Proper database optimization starts with:
```
measure
 ↓
identify slow query
 ↓
EXPLAIN
 ↓
understand access pattern
 ↓
optimize
 ↓
measure again
```
51. MySQL RAM

MySQL uses RAM for several purposes:
```
InnoDB buffer pool
connections
sort buffers
temporary structures
internal caches
other server memory
```
Therefore:
```
MySQL RAM usage
```
is more than simply:
```
buffer pool
```
52. Buffer Pool Sizing

On a dedicated database server, the InnoDB buffer pool can often occupy a large fraction of available memory.

But your server is not a dedicated MySQL server.

You also run:
```
Nginx
PHP-FPM
WordPress
OS
other services
```
Therefore you cannot simply allocate almost all RAM to MySQL.

53. Shared VPS

Your server might look like:
```
RAM
│
├── Linux
├── Nginx
├── PHP-FPM
├── MySQL
├── SSH
├── monitoring
└── other services
```
So resource planning must consider the entire stack.

54. PHP-FPM vs MySQL Memory

Suppose:
```
PHP-FPM
 ↓
many workers
 ↓
high RAM usage
```
At the same time:
```
MySQL
 ↓
large buffer pool
 ↓
high RAM usage
```
Together they can exhaust the server.

55. Swap

Linux may use swap when memory pressure occurs.

Conceptually:
```
RAM
 ↓
memory pressure
 ↓
swap
 ↓
disk
```
Swap is much slower than RAM.

It can help prevent immediate process termination in some situations, but heavy swapping can severely hurt performance.

56. OOM Killer

If the Linux system runs critically short of memory, the kernel may invoke the:

Out-Of-Memory Killer

Conceptually:
```
RAM exhausted
 ↓
kernel attempts recovery
 ↓
process may be killed
```
This is why poor PHP-FPM/MySQL memory planning can cause apparently random service failures.

57. Check Memory

On Ubuntu:
```
free -h
```
This gives a quick overview.

You can also use:
```
htop
```
if installed.

58. Check Disk
```
df -h
```
Remember:
```
RAM
≠
Disk
```
They are completely different resources.

59. Check MySQL Processes
```
ps aux | grep mysqld
```
or:
```
ps aux | grep mariadbd
```
depending on the database software.

60. MySQL Status

Inside MySQL:
```
SHOW STATUS;
```
There are many metrics.

You can also query specific status variables.

61. Connection Count

A useful metric:
```
SHOW STATUS LIKE 'Threads_connected';
```
This tells you the current number of connected client threads.

62. Maximum Connections

You can inspect:
```
SHOW VARIABLES LIKE 'max_connections';
```
This is a limit on concurrent client connections.

Again, setting it extremely high isn’t automatically good.

Each connection can consume resources.

63. Too Many Connections

If MySQL reaches its connection limit:
```
PHP-FPM
 ↓
new connection
 ↓
MySQL
 ↓
too many connections
 ↓
failure
```
WordPress may then report database connection errors.

64. Classic WordPress Error

A famous WordPress message is:

Error establishing a database connection.

Possible causes include:
```
MySQL stopped
Wrong database credentials
Wrong DB host
Network/socket problem
Too many connections
Database overload
Corruption
Resource exhaustion
```
65. Diagnostic Sequence

If WordPress reports a database connection error:
```
1. Is MySQL running?
2. Is the database present?
3. Does the database user exist?
4. Are credentials correct?
5. Can the user access the database?
6. Is MySQL listening?
7. Is the socket available?
8. Is the server overloaded?
9. Are connections exhausted?
```
66. Check MySQL
```
sudo systemctl status mysql
```
Then:
```
sudo journalctl -u mysql -n 100
```
67. Test Database Login

If appropriate:
```
mysql -u wordpress_user -p wordpress_db
```
You’ll be prompted for the password.

Do not place database passwords directly into shell history unnecessarily.

68. Check Database Exists

Inside MySQL:
```
SHOW DATABASES;
```
Then:
```
USE wordpress_db;
```
69. Check Tables
```
SHOW TABLES;
```
If you see:
```
wp_posts
wp_users
wp_options
...
```
the WordPress database is present.

70. Check WordPress Options

A useful diagnostic:
```
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');
```
This helps confirm important URL configuration values.

71. Why URL Configuration Matters

Suppose the site was originally:
```
https://oldsite.com
```
and you migrate it to:
```
https://newsite.com
```
but database values still reference:
```
oldsite.com
```
you can experience:
```
redirect problems
incorrect asset URLs
login problems
mixed-content issues
```
Migration therefore involves both:
```
files
+
database
```
72. Database Backup

For WordPress hosting, one of the most important operational principles is:

A website backup must include both filesystem data and database data.

Conceptually:
```
Backup
│
├── Website files
│
└── MySQL database
```
73. Why Copying public/ Is Not Enough

Suppose you copy:
```
/storage/websites/example.com/public/
```
You have the PHP code and uploads.

But you don’t necessarily have:
```
posts
users
settings
menus
plugin configuration
```
Those are in the database.

74. Database Restore

A logical backup might look like:
```
wordpress.sql
```
Restoration conceptually:
```
SQL dump
 ↓
MySQL
 ↓
database
 ↓
WordPress
```
A proper disaster-recovery plan should test this process periodically.

75. Database and Hosting Automation

Your hosting platform can eventually automate:
```
Create website
 ↓
Create database
 ↓
Create database user
 ↓
Grant permissions
 ↓
Generate wp-config.php
 ↓
Install WordPress
```
This is a major part of a hosting control panel.

76. Your Hosting Platform Architecture

You are gradually building toward:
```
CresignSys Hosting Platform
│
├── Domain management
├── DNS
├── Website directories
├── Nginx
├── SSL
├── PHP-FPM
├── PHP versions
├── MySQL
├── Database users
├── WordPress
├── Backups
├── Logs
└── Monitoring
```
Each of these is now becoming understandable as an individual layer.

77. The Complete Internal Path

Let’s trace one WordPress database request extremely deeply.
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
PHP worker
 ↓
WordPress
 ↓
SQL query
 ↓
MySQL connection
 ↓
SQL parser
 ↓
Query optimizer
 ↓
Execution plan
 ↓
InnoDB
 ↓
Index
 ↓
Buffer pool
 ↓
Data page
 ↓
RAM
```
If the required page isn’t in memory:
```
Buffer Pool
 ↓
Disk I/O
 ↓
Storage
 ↓
page loaded
 ↓
RAM
 ↓
InnoDB
 ↓
WordPress
```
78. Now Think About Performance

A page can become slow at many different points:
```
DNS
 ↓
Network
 ↓
TLS
 ↓
Nginx
 ↓
PHP-FPM queue
 ↓
PHP execution
 ↓
WordPress plugin
 ↓
MySQL query
 ↓
Disk I/O
```
Therefore:

“The website is slow” is not a diagnosis.

It is only a symptom.

79. Performance Diagnosis

The correct approach is:
```
Measure
   ↓
Find slow layer
   ↓
Measure that layer
   ↓
Find bottleneck
   ↓
Fix bottleneck
   ↓
Measure again
```
This principle will become extremely important as you manage more websites.

80. Four Major Resources

For your VPS, constantly think about:
```
CPU
RAM
Disk I/O
Network
```
A fifth practical resource is:
```
Database/application capacity
```
although it ultimately consumes the underlying resources.

81. CPU Bottleneck

Could look like:
```
PHP
 ↓
CPU 100%
```
Possible causes:
```
expensive plugin
heavy PHP computation
many simultaneous requests
bad application code
bot traffic
```
82. RAM Bottleneck

Could look like:
```
RAM
 ↓
nearly exhausted
 ↓
swap/OOM
```
Possible causes:
```
too many PHP workers
large MySQL memory allocation
memory-heavy plugins
many concurrent requests
```
83. Disk Bottleneck

Could look like:
```
Disk I/O
 ↓
high latency
```
Possible causes:
```
database writes
backups
logs
cache operations
large file operations
swap
```
84. Network Bottleneck

Could occur when:
```
large downloads/uploads
high traffic
many connections
```
consume network capacity.

85. Database Bottleneck

Could be:
```
MySQL
 ↓
slow queries
 ↓
PHP waits
 ↓
Nginx waits
 ↓
Browser waits
```
This is why understanding MySQL internals matters to web hosting.

86. One More Important Concept: Concurrency

Suppose:
```
1 visitor
```
requests a page.

Easy.

Now:
```
100 visitors
```
arrive simultaneously.

The architecture becomes:
```
100 HTTP requests
        ↓
      Nginx
        ↓
PHP-FPM workers
        ↓
WordPress
        ↓
MySQL connections/queries
```
Every layer must handle concurrency.

87. PHP-FPM Queue

If all PHP workers are busy:
```
Request
 ↓
PHP-FPM
 ↓
no worker available
 ↓
wait
```
This increases response time.

88. MySQL Queue/Contention

Similarly, if MySQL is overloaded:
```
PHP workers
 ↓
database requests
 ↓
MySQL contention
 ↓
queries take longer
```
So increasing PHP-FPM workers can sometimes make an overloaded MySQL server even busier.

89. This Is Why Tuning Must Be Holistic

Don’t think:
```
Website slow
 ↓
increase PHP workers
```
Instead:
```
Website slow
 ↓
measure
 ↓
PHP?
MySQL?
Disk?
CPU?
Network?
Application?
```
Then make the appropriate change.

90. MySQL’s Deepest Simplified Model

Remember:
```
SQL
 ↓
Parser
 ↓
Optimizer
 ↓
Execution
 ↓
InnoDB
 ↓
Index/Data
 ↓
Buffer Pool
 ↓
Disk when needed
```
And for changes:
```
Write
 ↓
memory/data structures
 ↓
redo logging
 ↓
eventual page flushing
 ↓
persistent storage
```
This is a simplified conceptual model, not a complete description of every internal operation.

91. What You Should Know Now

You have progressed from:
```
"WordPress is a website"
```
to:
```
Browser
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
 ↓
WordPress
 ↓
SQL
 ↓
MySQL
 ↓
InnoDB
 ↓
Buffer Pool
 ↓
Disk
```
That is a substantial part of the foundation of modern PHP hosting.

Lesson 046 Summary

The key concepts are:
```
Parser
=
understands SQL syntax

Optimizer
=
chooses an execution strategy

EXPLAIN
=
shows query execution plan

Index
=
helps locate data efficiently

InnoDB
=
major MySQL storage engine

Buffer Pool
=
RAM area used to cache InnoDB data/index pages

Dirty Page
=
modified in-memory page not yet fully persisted

Redo Log
=
supports durability/recovery

Undo
=
supports rollback and consistent transactional behavior

Transaction
=
logical group of database operations
```
The most important mental model:
```
WordPress
   ↓
SQL
   ↓
MySQL
   ↓
Optimizer
   ↓
InnoDB
   ↓
Buffer Pool
   ↓
Disk
```
Next Lesson — 047

Linux Networking From Zero — What Actually Happens Between Your VPS and the Internet

We will go below Nginx and learn:
```
Network interface
IP address
MAC address
Ethernet
ARP
Subnet
Gateway
Routing table
TCP
UDP
Ports
Sockets
NAT
Firewall
IPv4
IPv6
```
Then connect it directly to your Oracle Cloud VPS:
```
Internet
   ↓
Public IP
   ↓
VNIC
   ↓
Subnet
   ↓
Route table
   ↓
Security rules
   ↓
Ubuntu
   ↓
Nginx
   ↓
Website
```
This will explain why a domain can resolve correctly but a website can still be unreachable, and how DNS, Oracle Cloud networking, Ubuntu firewall, ports 80/443, Nginx, and the browser all fit together.
August 13, 2026
CresignSys Learn — Lesson 045
MySQL From the Absolute Basics

We now go one layer deeper.

Our current architecture is:
```
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
Today we study:

MySQL

This is where WordPress stores most of its structured application data.

1. What Is Data?

Before MySQL, understand the simplest concept:

Data is information represented in a form that a computer can store and process.

Examples:
```
Name:
Abey

Email:
example@example.com

Post title:
My First Website

Price:
499

Date:
2026-08-13
```
A database organizes this information.

2. What Is a Database?

A database is a system for storing and retrieving structured information.

Think:
```
Database
│
├── Users
├── Products
├── Orders
├── Settings
└── Content
```
WordPress needs a database because a website contains much more than static files.

3. Why Can’t WordPress Just Use Files?

Some information is stored in files:
```
WordPress
├── PHP files
├── CSS
├── JavaScript
├── Images
└── Configuration
```
But imagine storing thousands of posts, users, comments, settings, relationships, and metadata entirely as individual files.

Searching and managing that information would become inefficient and complicated.

A database provides structured querying.

4. MySQL

MySQL is a:

Relational Database Management System

Often abbreviated:

RDBMS

The important word is:

Relational

Data is organized into related tables.

5. MySQL Is Not WordPress

Keep these separate:
```
MySQL
=
database management system
```
```
WordPress
=
web application
```
Relationship:
```
WordPress
   ↓
MySQL
```
WordPress uses MySQL to store and retrieve its data.

6. MySQL Is Not the Database Itself

A useful distinction:
```
MySQL
=
software/database server
```
Inside MySQL you can have:
```
Databases
```
Inside databases:
```
Tables
```
Inside tables:
```
Rows
```
Inside rows:
```
Columns
```
7. Hierarchy

Memorize:
```
MySQL Server
    │
    ├── Database A
    │     ├── Table
    │     ├── Table
    │     └── Table
    │
    └── Database B
          ├── Table
          └── Table
```
For WordPress:
```
MySQL Server
    ↓
wordpress_database
    ↓
WordPress tables
```
8. Database

Suppose your WordPress database is called:
```
wordpress_db
```
It may contain:
```
wordpress_db
│
├── wp_posts
├── wp_users
├── wp_options
├── wp_postmeta
├── wp_terms
└── ...
```
The actual prefix may not be wp_.

9. Table

A table is a structured collection of related records.

Imagine:
```
wp_users
```
Conceptually:

ID user_login user_email
1 admin admin@example.com
2 john john@example.com

Each horizontal record is a:

Row

10. Column

A column represents a particular type of information.

For example:
```
wp_users
```
might contain columns such as:
```
ID
user_login
user_pass
user_email
user_registered
```
So:
```
Column
=
one attribute/field of the table
```
11. Row

A row represents one record.

Example:
```
1 | admin | admin@example.com
```
This represents one user record.

12. Cell

The intersection of:
```
row
+
column
```
is a cell/value.

For example:
```
user_email
```
for user ID 1 might contain:
```
admin@example.com
```
13. SQL

SQL means:

Structured Query Language

It is used to communicate with relational databases.

For example:
```
SELECT * FROM wp_users;
```
This means approximately:

Retrieve all rows from wp_users.

14. SQL Is a Language

Think:
```
PHP
=
programming language

SQL
=
database query language
```
WordPress PHP code can execute SQL queries against MySQL.

15. Basic SELECT

Example:
```
SELECT * FROM wp_posts;
```
Break it down:
```
SELECT
=
retrieve data

*
=
all selected columns

FROM
=
source table

wp_posts
=
table
```
16. Select Specific Columns

Instead of:
```
SELECT * FROM wp_users;
```
you can request:
```
SELECT ID, user_login, user_email
FROM wp_users;
```
This retrieves only the specified columns.

17. WHERE

Suppose you want user ID 5:
```
SELECT *
FROM wp_users
WHERE ID = 5;
```
Conceptually:
```
wp_users
   ↓
find ID = 5
   ↓
return matching row
```
18. SQL Filtering

Example:
```
SELECT *
FROM wp_posts
WHERE post_status = 'publish';
```
This asks for published posts.

19. INSERT

To add a record:
```
INSERT INTO ...
```
Conceptually:
```
INSERT INTO wp_users (...)
VALUES (...);
```
This creates a new database row.

20. UPDATE

To modify existing data:
```
UPDATE ...
```
Example conceptually:
```
UPDATE wp_options
SET option_value = '...'
WHERE option_name = '...';
```
21. DELETE

To remove records:
```
DELETE FROM ...
```
Example:
```
DELETE FROM table_name
WHERE id = 10;
```
Be extremely careful with DELETE.

22. The Most Dangerous SQL Mistake

Never casually execute:
```
DELETE FROM wp_posts;
```
without a precise understanding of what you’re doing.

Even more dangerous:
```
DELETE FROM wp_posts;
```
without a WHERE clause.

That can remove every row in the table.

23. WordPress Database

A normal WordPress installation creates a collection of tables.

Common examples:
```
wp_posts
wp_postmeta
wp_users
wp_usermeta
wp_options
wp_terms
wp_term_taxonomy
wp_term_relationships
wp_comments
wp_commentmeta
```
Plugins can create additional tables.

24. wp_posts

Despite the name, this table isn’t only for blog posts.

It can contain different WordPress content types, including:
```
Posts
Pages
Custom post types
Attachments
Revisions
```
The exact rows depend on the site’s content.

25. post_type

One important column is:
```
post_type
```
It distinguishes types of content.

Examples include:
```
post
page
attachment
revision
```
Plugins can introduce custom post types.

26. Example

Conceptually:

ID post_title post_type post_status
10 About Us page publish
11 Welcome post publish
12 Logo attachment inherit

So one table can represent multiple types of WordPress objects.

27. post_status

Another important field:
```
post_status
```
Examples can include:
```
publish
draft
pending
private
trash
inherit
```
WordPress uses these states to determine how content is handled.

28. wp_postmeta

WordPress needs additional information about posts.

That’s where:
```
wp_postmeta
```
comes in.

Conceptually:
```
wp_posts
   │
   │ post ID
   ▼
wp_postmeta
```
29. Metadata

Metadata means:

Additional information associated with another object.

For a post:
```
Post
│
├── title
├── content
├── status
└── metadata
      ├── custom field
      ├── layout
      └── plugin data
```
30. meta_key and meta_value

wp_postmeta commonly contains:
```
post_id
meta_key
meta_value
```
Example conceptually:

post_id meta_key meta_value
10 page_template default
10 custom_color blue

The actual data depends on themes/plugins.

31. wp_users

This table stores user records.

Common fields include:
```
ID
user_login
user_pass
user_nicename
user_email
user_url
user_registered
display_name
```
32. Passwords

Important:

WordPress should not store user passwords as plain text.

The database contains password hashes.

Conceptually:
```
Password
   ↓
password hashing
   ↓
stored hash
```
33. Hashing vs Encryption

These are different.

Encryption
```
data
 ↓
encryption
 ↓
encrypted data
 ↓
decryption
 ↓
original data
```
Password hashing
```
password
 ↓
hash
 ↓
stored result
```
You don’t normally “decrypt” a password hash to obtain the original password.

34. wp_usermeta

Additional user information is commonly stored in:
```
wp_usermeta
```
For example:
```
user ID
role/capability metadata
preferences
plugin-specific data
```
35. User Relationships

Conceptually:
```
wp_users
   │
   │ ID
   ▼
wp_usermeta
```
This is an example of a relational relationship.

36. wp_options

One of the most important WordPress tables:
```
wp_options
```
It stores site-wide configuration/options.

Examples include:
```
siteurl
home
blogname
active_plugins
stylesheet
template
```
and many plugin/theme settings.

37. siteurl

WordPress commonly stores the site’s URL in:
```
siteurl
```
For example:
```
https://templates.cresignsys.com
```
38. home

Another important option is:
```
home
```
It represents the site’s front-end URL.

Depending on configuration, home and siteurl can be the same or intentionally different.

39. Why wp_options Matters

If WordPress cannot correctly read its options:
```
WordPress
 ↓
configuration problems
 ↓
website errors
```
A corrupted or incorrectly modified wp_options table can affect the entire site.

40. wp_terms

WordPress uses taxonomy concepts such as:
```
Categories
Tags
Custom taxonomies
```
The term information is stored through tables such as:
```
wp_terms
wp_term_taxonomy
wp_term_relationships
```
41. Taxonomy

A taxonomy is a system for grouping/classifying content.

For example:
```
Post
│
├── Category: Technology
├── Category: Hosting
└── Tag: Nginx
```
42. wp_term_relationships

This table connects content to taxonomy terms.

Conceptually:
```
Post
  │
  ▼
relationship
  │
  ▼
Term
```
This is a database relationship.

43. Why Multiple Tables?

You might wonder:

Why not put everything into one giant table?

Because relational databases organize information into logical structures.

Instead of:
```
ONE HUGE TABLE
```
we have:
```
Posts
Users
Terms
Metadata
Comments
Options
```
with relationships between them.

44. Database Normalization

This design principle is related to:

Normalization

Normalization attempts to organize data so that unnecessary duplication is reduced and relationships are represented cleanly.

It has several normal forms, such as:
```
1NF
2NF
3NF
```
WordPress’s schema is application-specific and isn’t a textbook example of perfectly normalized relational design everywhere, but the concepts are still important for understanding relational databases.

45. Primary Key

A table often has a:

Primary Key

It uniquely identifies a row.

For wp_posts:
```
ID
```
is the primary identifier.

Conceptually:
```
wp_posts
ID
│
├── 1
├── 2
├── 3
└── 4
```
Each identifies a particular record.

46. Why Primary Keys Matter

Suppose:
```
post ID = 100
```
WordPress can refer to that specific post.

Other tables can store:
```
post_id = 100
```
to associate information with it.

47. Foreign Key Concept

A column that refers to a record in another table is conceptually a:

Foreign Key

For example:
```
wp_postmeta.post_id
```
refers to:
```
wp_posts.ID
```
WordPress often manages these relationships at the application level rather than relying exclusively on database-enforced foreign-key constraints.

48. Index

A database index helps find data efficiently.

Think about a book.

Without an index:
```
Search every page
```
With an index:
```
Go directly toward the relevant location
```
Database indexes serve a similar purpose.

49. Example

Suppose wp_posts contains:
```
1,000,000 rows
```
Searching every row repeatedly could be expensive.

An appropriate index can dramatically improve lookup performance for supported query patterns.

50. Index Trade-Off

Indexes aren’t free.

They consume:
```
Disk
RAM
Write/update overhead
```
Therefore:

More indexes are not automatically better.

51. SQL Query Flow

When WordPress needs data:
```
WordPress PHP
   ↓
SQL query
   ↓
MySQL
   ↓
Query parser
   ↓
Query optimizer
   ↓
Storage engine
   ↓
Data
   ↓
Result
   ↓
WordPress
```
52. MySQL Storage Engine

MySQL can use storage engines.

The most common modern choice for WordPress is:

InnoDB

It provides features such as:
```
Transactions
Row-level locking
Crash recovery
Indexes
```
53. Transaction

A transaction groups database operations into a logical unit.

Conceptually:
```
BEGIN
   operation 1
   operation 2
   operation 3
COMMIT
```
If something goes wrong:
```
ROLLBACK
```
can undo the transaction’s changes, subject to the database/application behavior.

54. ACID

Database transactions are often discussed using:

ACID
```
A = Atomicity
C = Consistency
I = Isolation
D = Durability
```
55. Atomicity

A transaction should be treated as an all-or-nothing unit.

Conceptually:
```
3 operations
 ↓
all succeed
 ↓
COMMIT
```
or:
```
failure
 ↓
ROLLBACK
```
56. Consistency

The database should move from one valid state to another valid state according to its constraints and rules.

57. Isolation

Concurrent transactions should not improperly interfere with each other.

This becomes important when many WordPress requests access MySQL simultaneously.

58. Durability

Once a transaction is committed, the database system is designed to preserve the committed data through normal failures, subject to hardware, configuration, and recovery assumptions.

59. MySQL Connection

PHP-FPM workers connect to MySQL.

Conceptually:
```
PHP Worker
    │
    ▼
MySQL connection
    │
    ▼
MySQL server
```
Multiple PHP workers can create concurrent database activity.

60. Database User

WordPress normally uses a dedicated MySQL account.

For example:
```
wordpress_user
```
with permissions on:
```
wordpress_db
```
61. Least Privilege

Don’t use the MySQL root account for WordPress.

Better:
```
WordPress
 ↓
wordpress_user
 ↓
wordpress_db
```
The database account should have only the privileges required by the application.

62. WordPress wp-config.php

WordPress needs database connection information.

Conceptually:
```
define('DB_NAME', 'wordpress_db');
define('DB_USER', 'wordpress_user');
define('DB_PASSWORD', '...');
define('DB_HOST', 'localhost');
```
The exact values depend on your installation.

63. DB_HOST

The database server could be:
```
localhost
```
or:
```
127.0.0.1
```
or a remote database hostname.

For many single-server WordPress installations:
```
WordPress
 ↓
same VPS
 ↓
MySQL
```
64. Localhost vs 127.0.0.1

These can behave differently depending on the client library and configuration.

For MySQL on Linux, localhost often results in Unix-socket communication, while 127.0.0.1 uses TCP.

This is a useful detail when diagnosing connection problems.

65. MySQL Unix Socket

A local MySQL server may expose a socket such as:
```
/run/mysqld/mysqld.sock
```
Then:
```
PHP
 ↓
Unix socket
 ↓
MySQL
```
can occur.

66. MySQL TCP

Alternatively:
```
PHP
 ↓
127.0.0.1:3306
 ↓
MySQL
```
Port:
```
3306
```
is the conventional MySQL TCP port.

It can be configured differently.

67. Check MySQL Service

On Ubuntu:
```
sudo systemctl status mysql
```
You may see:
```
Active: active (running)
```
68. Check MySQL Version
```
mysql --version
```
Your server has previously been using MySQL 8.x.

The exact installed version should be checked before making configuration decisions.

69. Connect to MySQL

If you have administrative access:
```
sudo mysql
```
Depending on your authentication configuration, this may open the MySQL shell.

You might see:
```
mysql>
```
70. SHOW DATABASES

Inside MySQL:
```
SHOW DATABASES;
```
You may see:
```
information_schema
mysql
performance_schema
sys
wordpress_db
```
71. Select a Database
```
USE wordpress_db;
```
Now subsequent table commands operate against that database unless otherwise specified.

72. Show Tables
```
SHOW TABLES;
```
You may see:
```
wp_options
wp_posts
wp_postmeta
wp_users
...
```
73. Inspect Table Structure

Use:
```
DESCRIBE wp_posts;
```
or:
```
SHOW COLUMNS FROM wp_posts;
```
This shows columns and their types.

74. Example Data Types

MySQL has data types such as:
```
INT
BIGINT
VARCHAR
TEXT
DATETIME
DECIMAL
BOOLEAN-like types
JSON
```
The appropriate type depends on the data.

75. INT

Used for integer values.

Example:
```
1
25
1000
```
76. VARCHAR

Variable-length text.

Example:
```
VARCHAR(255)
```
can store text up to a specified maximum length.

77. TEXT

Used for larger text content.

WordPress post content can be large, so text-oriented columns are important.

78. DATETIME

Stores date/time values.

WordPress has many timestamps such as:
```
post_date
post_modified
user_registered
```
79. WordPress Data Flow

When you create a new page in WordPress:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
SQL INSERT/UPDATE
 ↓
MySQL
 ↓
database
```
The page’s information is stored in the database.

80. What About Images?

This is important.

WordPress image data is split between:
```
Database
+
Filesystem
```
The actual image file generally lives under:
```
wp-content/uploads/
```
while information about the attachment is stored in the database.

Conceptually:
```
Image
├── Actual file
│     ↓
│  filesystem
│
└── Metadata
      ↓
    MySQL
```
81. WordPress Is Hybrid Storage

This is a key concept:
```
WordPress
│
├── Code
│    ↓
│  filesystem
│
├── Media
│    ↓
│  filesystem
│
└── Structured application data
     ↓
   MySQL
```
82. Plugin Installation

When you install a plugin:
```
Plugin PHP files
 ↓
filesystem
```
But plugin configuration may be stored in:
```
wp_options
```
Some plugins also create their own tables.

So one plugin can use both:
```
Filesystem
+
Database
```
83. Theme Installation

Similarly:
```
Theme files
 ↓
wp-content/themes/
```
Theme settings may be stored in:
```
wp_options
```
or other WordPress metadata structures.

84. User Creation

When you create a WordPress user:
```
Browser
 ↓
WordPress
 ↓
MySQL
```
data goes into tables such as:
```
wp_users
wp_usermeta
```
85. Creating a Post

Creating a post involves information such as:
```
title
content
author
status
date
slug
```
and may involve:
```
wp_posts
wp_postmeta
wp_terms
wp_term_relationships
```
depending on the content and taxonomy.

86. Database Slowness

Suppose your website takes 5 seconds to generate a page.

Possible chain:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
slow query
```
So the browser may experience:
```
5-second response
```
even though Nginx itself is fast.

87. Database Query Optimization

One area of performance tuning is:
```
SQL query
 ↓
EXPLAIN
 ↓
query plan
 ↓
identify bottleneck
```
For example:
```
EXPLAIN SELECT ...
```
This helps understand how MySQL intends to execute a query.

88. Slow Queries

MySQL can record slow queries through its slow-query log.

Conceptually:
```
WordPress
 ↓
slow SQL
 ↓
MySQL
 ↓
slow query log
```
This is useful when diagnosing database performance.

89. Database Size

Check the database size from MySQL.

For example:
```
SELECT
    table_schema AS database_name,
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'wordpress_db'
GROUP BY table_schema;
```
This can help identify large databases.

90. Large WordPress Databases

A WordPress database can grow because of:
```
Posts
Revisions
Comments
Metadata
Plugin data
WooCommerce data
Logs
Transients
Analytics
```
Plugins are often responsible for significant database growth.

91. Database Backups

A WordPress backup is not complete if you only copy:
```
public/
```
You also need the database.

Conceptually:
```
Complete WordPress backup
│
├── Files
│
└── Database
```
92. Files Backup

For example:
```
wp-content/
wp-config.php
WordPress files
```
plus any relevant server configuration.

93. Database Backup

A common tool is:
```
mysqldump
```
For example, conceptually:
```
mysqldump -u wordpress_user -p wordpress_db > wordpress.sql
```
This creates a logical SQL backup.

Be careful with credentials and backup file permissions.

94. Restore

A SQL dump can be restored into a database.

Conceptually:
```
wordpress.sql
 ↓
MySQL
 ↓
database
```
A proper restore process should be tested rather than assumed.

95. Disaster Recovery

For your hosting platform:
```
Website
│
├── Files backup
├── Database backup
├── Nginx configuration
├── SSL configuration/state
└── DNS information
```
A real backup strategy should also include off-server storage and restoration testing.

96. MySQL Is a Separate Service

Your VPS may have:
```
nginx.service
php8.x-fpm.service
mysql.service
```
These are separate processes/services.

Conceptually:
```
Ubuntu
│
├── Nginx
├── PHP-FPM
└── MySQL
```
97. If MySQL Stops

The website may still load static files:
```
/logo.png
/style.css
```
but dynamic WordPress requests may fail or behave incorrectly because WordPress cannot retrieve its database data.

98. If PHP-FPM Stops

Nginx may still serve static files.

But PHP requests can fail:
```
.php
 ↓
PHP-FPM unavailable
 ↓
502
```
99. If Nginx Stops

The web server itself becomes unavailable even if:
```
PHP-FPM ✓
MySQL ✓
```
This illustrates why services form a chain.

100. Service Dependency Chain
```
Browser
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
A failure at one layer can affect everything above it.

101. The Deep Architecture

We can now draw the complete architecture we’ve learned:
```
                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP/Route
                            │
                            ▼
                       TCP / QUIC
                            │
                            ▼
                           TLS
                            │
                            ▼
                          HTTP
                            │
                            ▼
                          NGINX
                            │
                         FastCGI
                            │
                            ▼
                         PHP-FPM
                            │
                            ▼
                       PHP Worker
                            │
                            ▼
                         WORDPRESS
                         /       \
                        /         \
                       ▼           ▼
                 FILESYSTEM      MySQL
                    │              │
                    ▼              ▼
               wp-content/     wp_posts
               plugins/        wp_users
               themes/         wp_options
               uploads/       wp_postmeta
                               wp_terms
```
This is now a real hosting architecture rather than just a list of technologies.

102. The Three Major Storage Areas

For WordPress, think in three categories:

1. Application code
```
PHP
CSS
JS
```
stored primarily in the filesystem.

2. Media
```
Images
Videos
Documents
```
stored primarily in the filesystem.

3. Structured application data
```
Posts
Users
Settings
Metadata
Relationships
```
stored primarily in MySQL.

103. Most Important MySQL Vocabulary

Memorize:
```
Database
=
collection of related tables

Table
=
structured collection of records

Row
=
one record

Column
=
one field/attribute

SQL
=
database query language

Primary Key
=
unique row identifier

Index
=
data structure for efficient lookup

Query
=
request to database

Transaction
=
group of database operations

MySQL
=
relational database management system
```
104. WordPress Vocabulary

Memorize:
```
wp_posts
=
posts/pages/content

wp_postmeta
=
post metadata

wp_users
=
users

wp_usermeta
=
user metadata

wp_options
=
site/application settings

wp_terms
=
taxonomy terms

wp_term_relationships
=
content ↔ taxonomy relationships
```
The prefix may differ from wp_.

105. The Complete Request Now

A visitor requests:
```
https://templates.cresignsys.com/about/
```
The full journey is:
```
Browser
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
 ↓
WordPress
 ↓
SQL
 ↓
MySQL
 ↓
wp_posts / wp_options / etc.
 ↓
result
 ↓
WordPress
 ↓
PHP
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Browser
```
106. The Next Layer

We now understand:
```
Internet
DNS
IP
TCP
TLS
HTTP
Nginx
Linux filesystem
Linux permissions
PHP-FPM
PHP
WordPress
MySQL
```
The next question is:

How does MySQL itself store data on the disk?

That takes us deeper into:
```
MySQL
 ↓
InnoDB
 ↓
pages
 ↓
indexes
 ↓
buffer pool
 ↓
redo log
 ↓
undo log
 ↓
disk
```
That is where database theory meets actual server storage.

Next Lesson — 046

MySQL Deep Internals — From SQL Query to Disk

We will trace:
```
WordPress
 ↓
SQL
 ↓
MySQL
 ↓
Query Parser
 ↓
Optimizer
 ↓
Execution
 ↓
InnoDB
 ↓
Buffer Pool
 ↓
Indexes
 ↓
Data Pages
 ↓
Redo Log
 ↓
Disk
```
Then we will connect this to why a WordPress website becomes slow, how database indexes work, why RAM matters, what MySQL cache/buffer memory does, and how to diagnose MySQL performance on your Ubuntu VPS.
August 13, 2026
CresignSys Learn — Lesson 044
PHP-FPM From the Absolute Basics

We now have:
```
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
?
```
The missing component is:

PHP-FPM

This is one of the most important technologies to understand if you want to build and manage WordPress hosting.

1. First: What Is PHP?

PHP is a programming language commonly used for server-side web applications.

WordPress is primarily written in PHP.

For example:
```
<?php
echo "Hello World";
```
A PHP program runs on the server.

The browser normally does not receive the PHP source code.

Instead:
```
PHP source
   ↓
PHP interpreter
   ↓
Generated result
   ↓
HTML
   ↓
Browser
```
2. PHP Is Server-Side

Compare:

HTML
```
<h1>Hello</h1>
```
The browser receives and interprets the HTML.

PHP
```
<?php
echo "<h1>Hello</h1>";
```
The server executes the PHP first.

The browser receives the resulting HTML:
```
<h1>Hello</h1>
```
3. Simple Example

Suppose the server contains:
```
/storage/websites/example.com/public/index.php
```
with:
```
<?php

$name = "CresignSys";

echo "<h1>Hello $name</h1>";
```
The browser requests:
```
/
```
The server executes PHP.

The browser receives:
```
<h1>Hello CresignSys</h1>
```
It does not normally receive:
```
$name = "CresignSys";
```
4. PHP Interpreter

Something must actually execute PHP code.

That component is the PHP interpreter/runtime.

Conceptually:
```
PHP file
   ↓
PHP runtime
   ↓
execution
   ↓
output
```
But where does PHP-FPM fit?

5. What Does FPM Mean?

FPM means:

FastCGI Process Manager

So:
```
PHP-FPM
=
PHP FastCGI Process Manager
```
It manages PHP worker processes that execute PHP applications.

6. Why Do We Need PHP-FPM?

Nginx is excellent at serving HTTP traffic.

But Nginx is not a PHP interpreter.

Therefore:
```
Browser
   ↓
Nginx
   ↓
PHP-FPM
   ↓
PHP
```
Nginx handles the web side.

PHP-FPM manages PHP execution.

7. Nginx and PHP-FPM Have Different Jobs

Nginx

Handles:
```
HTTP
TLS
routing
static files
connections
headers
reverse proxying
```
PHP-FPM

Handles:
```
PHP workers
PHP execution
worker lifecycle
PHP process management
```
WordPress

Handles:
```
pages
posts
plugins
themes
users
database queries
application logic
```
8. The Complete Flow

When somebody visits:
```
https://templates.cresignsys.com/about/
```
the simplified flow is:
```
Browser
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
PHP
   ↓
WordPress
   ↓
MySQL
```
Then the result travels back.

9. What Is FastCGI?

FastCGI is a protocol/interface for communicating between a web server and an application process manager.

Conceptually:
```
Nginx
  │
  │ FastCGI
  ▼
PHP-FPM
```
Nginx sends information about the HTTP request.

PHP-FPM passes it to a PHP worker.

10. Why Not Just Start PHP for Every Request?

Imagine:
```
Request 1
 ↓
start PHP
 ↓
execute
 ↓
stop PHP

Request 2
 ↓
start PHP
 ↓
execute
 ↓
stop PHP
```
That would introduce unnecessary process-start overhead.

PHP-FPM keeps a managed pool of workers.

11. Worker Processes

Think of PHP-FPM as a team of PHP workers.
```
PHP-FPM
│
├── Worker 1
├── Worker 2
├── Worker 3
├── Worker 4
└── Worker 5
```
Requests can be assigned to available workers.

12. Why Multiple Workers?

Suppose 10 users access WordPress simultaneously.

If only one PHP worker can execute requests:
```
Request 1
Request 2
Request 3
...
```
they may wait behind one another.

With multiple workers:
```
Request 1 → Worker 1
Request 2 → Worker 2
Request 3 → Worker 3
Request 4 → Worker 4
```
multiple requests can be processed concurrently.

13. But More Workers Isn’t Always Better

This is extremely important.

More workers consume:
```
RAM
CPU
database connections
file descriptors
```
Suppose each PHP worker uses significant memory.

If you configure:
```
100 PHP workers
```
on a small VPS, you may exhaust RAM.

Therefore:

PHP-FPM worker configuration must match the server’s resources and workload.

14. PHP-FPM Pool

PHP-FPM organizes workers into:

Pools

A pool might look conceptually like:
```
Pool: www
│
├── Worker
├── Worker
├── Worker
└── Worker
```
The pool configuration controls how those workers operate.

15. Default Pool

On Ubuntu/Debian systems, a common default pool is:
```
www
```
Its configuration is often under something like:
```
/etc/php/<version>/fpm/pool.d/www.conf
```
For example:
```
/etc/php/8.3/fpm/pool.d/www.conf
```
Your installed PHP version may differ.

16. Find Your PHP Version

Run:
```
php -v
```
You might see:
```
PHP 8.x.x
```
But remember:

CLI PHP and PHP-FPM can be configured differently.

So also inspect:
```
systemctl list-units --type=service | grep php
```
17. Find PHP-FPM Services

Try:
```
systemctl list-units --type=service | grep fpm
```
You may see something like:
```
php8.3-fpm.service
```
18. Check PHP-FPM Status

For a specific version:
```
sudo systemctl status php8.3-fpm
```
Replace 8.3 with your installed version.

You want something similar to:
```
Active: active (running)
```
19. PHP-FPM Socket

Nginx needs somewhere to send FastCGI requests.

A common configuration is:
```
/run/php/php8.3-fpm.sock
```
This is a Unix socket.

20. Check PHP Sockets

Run:
```
ls -la /run/php/
```
You may see:
```
php8.3-fpm.sock
```
or multiple versions:
```
php8.1-fpm.sock
php8.2-fpm.sock
php8.3-fpm.sock
```
21. Nginx Configuration

You may have something like:
```
location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
```
This creates the connection:
```
Nginx
  ↓
Unix socket
  ↓
PHP-FPM
```
22. What Is a Unix Socket?

A Unix socket is a local communication endpoint.

Instead of using:
```
127.0.0.1:9000
```
Nginx can communicate through:
```
/run/php/php8.3-fpm.sock
```
Both processes are on the same server.

23. TCP Alternative

PHP-FPM can also listen on a TCP address.

Conceptually:
```
Nginx
 ↓
127.0.0.1:9000
 ↓
PHP-FPM
```
This is different from:
```
Nginx
 ↓
Unix socket
 ↓
PHP-FPM
```
Both are valid architectures.

24. Why Unix Sockets Are Common

For same-machine communication, Unix sockets can be convenient and efficient.

They also avoid exposing PHP-FPM on a network port unnecessarily.

25. PHP-FPM Pool Configuration

A simplified pool might contain:
```
[www]

user = www-data
group = www-data

listen = /run/php/php8.3-fpm.sock

pm = dynamic

pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
```
This is an educational example, not a recommended production configuration for your particular server.

26. user
```
user = www-data
```
means worker processes run under that user.

This connects directly to our previous lesson.
```
PHP-FPM
 ↓
www-data
 ↓
Linux permissions
```
27. group
```
group = www-data
```
sets the worker process group.

Again:
```
User
+
Group
+
Filesystem permissions
```
determine what PHP can access.

28. listen

Example:
```
listen = /run/php/php8.3-fpm.sock
```
This tells PHP-FPM where to receive FastCGI connections.

Nginx must point to the corresponding endpoint.

29. The Socket Must Match

If Nginx says:
```
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
```
but PHP-FPM is listening at:
```
/run/php/php8.2-fpm.sock
```
the connection will fail.

This can produce:

502 Bad Gateway

30. Classic 502 Problem
```
Browser
 ↓
Nginx
 ↓
PHP-FPM socket
      X
```
Possible reasons:
```
PHP-FPM stopped
Wrong socket
Wrong PHP version
Socket permissions
Pool configuration failure
PHP-FPM crashed
```
31. Check the Socket

Run:
```
ls -la /run/php/
```
Then compare it with:
```
sudo nginx -T | grep fastcgi_pass
```
This is a very useful diagnostic.

32. Process List

You can inspect PHP processes:
```
ps aux | grep php-fpm
```
or:
```
ps -ef | grep php-fpm
```
You may see:
```
root      php-fpm: master process
www-data  php-fpm: pool www
www-data  php-fpm: pool www
www-data  php-fpm: pool www
```
33. Master Process

PHP-FPM usually has a master process.

Conceptually:
```
PHP-FPM
│
└── Master
     │
     ├── Worker
     ├── Worker
     ├── Worker
     └── Worker
```
The master manages the worker pool.

34. Worker Process

Workers perform PHP application work.

For example:
```
HTTP request
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Worker
 ↓
WordPress
```
35. pm

PHP-FPM has different process-management strategies.

Common modes include:
```
static
dynamic
ondemand
```
36. Static

With:
```
pm = static
```
PHP-FPM maintains a fixed number of workers.

Example:
```
pm.max_children = 10
```
means approximately 10 child workers.

37. Dynamic

With:
```
pm = dynamic
```
PHP-FPM dynamically manages the number of child processes within configured limits.

It uses settings such as:
```
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
```
38. Ondemand

With:
```
pm = ondemand
```
workers can be created when requests arrive and removed after an idle period.

This can be useful for some low-traffic workloads.

39. pm.max_children

This is one of the most important settings.

Example:
```
pm.max_children = 10
```
It limits the number of child processes in the pool.

Conceptually:
```
Maximum concurrent PHP workers
=
10
```
40. Why It Matters

Suppose:
```
RAM = 4 GB
```
and PHP workers consume significant memory.

If you allow:
```
100 workers
```
the system can run out of memory.

Possible result:
```
RAM exhaustion
 ↓
swap pressure
 ↓
slow server
 ↓
process termination
 ↓
website failures
```
41. PHP-FPM and RAM

A simplified model:
```
PHP worker memory
×
number of workers
≈
PHP memory requirement
```
This is only an approximation because real memory usage varies.

But it gives you the right mental model.

42. CPU Also Matters

PHP workers consume CPU.

Suppose:
```
100 requests
```
all execute heavy WordPress operations.

Then:
```
PHP
 ↓
CPU saturation
```
can occur.

So PHP-FPM tuning is not just about RAM.

43. Database Connections

PHP workers may also interact with MySQL.

If you have:
```
50 PHP workers
```
you can potentially have many database interactions occurring concurrently.

Therefore:
```
PHP-FPM capacity
```
must be considered together with:
```
MySQL capacity
```
44. WordPress Request

Let’s follow one request.

Browser:
```
GET /about/
```
Nginx:
```
Request matches location /
```
Then:
```
try_files
 ↓
index.php
```
Then:
```
FastCGI
 ↓
PHP-FPM
```
Then:
```
PHP worker
 ↓
WordPress
```
45. WordPress Loads

WordPress may load:
```
wp-config.php
wp-settings.php
plugins
theme
core files
```
Then it initializes the application.

46. WordPress Queries MySQL

For example, WordPress may need:
```
Site settings
Posts
Pages
Menus
Users
Metadata
Plugin settings
```
So:
```
PHP
 ↓
MySQL
 ↓
results
 ↓
PHP
```
47. PHP Generates HTML

WordPress eventually produces:
```
<html>
<head>
...
</head>
<body>
...
</body>
</html>
```
Then:
```
PHP worker
 ↓
PHP-FPM
 ↓
Nginx
 ↓
Browser
```
48. One Request May Be Expensive

A request can involve:
```
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
20+ plugins
 ↓
Theme
 ↓
MySQL
 ↓
External APIs
 ↓
HTML
```
That is why a “simple webpage” can involve significant server work.

49. PHP OPcache

PHP has an important performance feature:

OPcache

OPcache stores compiled PHP bytecode in shared memory.

Without OPcache, PHP may repeatedly parse/compile scripts.

Conceptually:
```
PHP source
 ↓
compile
 ↓
bytecode
 ↓
execute
```
With OPcache:
```
PHP source
 ↓
compile once
 ↓
OPcache
 ↓
reuse compiled code
```
50. Why OPcache Matters for WordPress

WordPress contains a large number of PHP files.

Plugins and themes add more.

OPcache can significantly reduce repeated compilation overhead.

51. Check OPcache

Run:
```
php -m | grep -i opcache
```
You can also inspect:
```
php -i | grep -i opcache
```
But remember that CLI PHP configuration may differ from FPM.

52. Check FPM PHP Configuration

A PHP-FPM process may use a configuration such as:
```
/etc/php/8.3/fpm/php.ini
```
while CLI PHP may use:
```
/etc/php/8.3/cli/php.ini
```
Therefore:
```
CLI PHP
≠
FPM PHP
```
necessarily.

53. Why This Matters

You might run:
```
php -i
```
and conclude:

PHP has this setting.

But your website may be running under PHP-FPM with a different configuration.

For website troubleshooting, inspect the FPM configuration.

54. php.ini

PHP configuration controls many runtime behaviors.

Examples include:
```
memory_limit
max_execution_time
upload_max_filesize
post_max_size
max_input_vars
date.timezone
```
55. memory_limit

Example:
```
memory_limit = 256M
```
This limits memory available to a PHP request under normal PHP memory accounting.

It does not mean:

Every PHP worker permanently consumes 256 MB.

Actual memory usage varies.

56. max_execution_time

Example:
```
max_execution_time = 60
```
This controls how long PHP code is allowed to execute under the relevant PHP semantics.

It is not a universal guarantee that every request will terminate exactly at that time because other layers also have timeouts.

57. upload_max_filesize

Example:
```
upload_max_filesize = 64M
```
This limits the size of an individual uploaded file at the PHP level.

58. post_max_size

Example:
```
post_max_size = 64M
```
This limits the maximum size of POST data PHP will accept.

It should generally be large enough relative to intended uploads.

59. Multiple Limits Exist

An upload can be restricted by several layers:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM/PHP
 ↓
WordPress
```
For example:
```
Nginx client_max_body_size
PHP upload_max_filesize
PHP post_max_size
WordPress/application limits
```
The smallest effective limit can become the practical restriction.

60. Nginx vs PHP-FPM

This distinction is important:
```
Nginx
=
receives HTTP request
```
```
PHP-FPM
=
runs PHP
```
```
PHP
=
language/runtime
```
```
WordPress
=
application
```
61. PHP-FPM Does Not Equal WordPress

Think:
```
PHP-FPM
   ↓
can run
   ↓
any compatible PHP application
```
It isn’t specifically a WordPress service.

It can run:
```
WordPress
Laravel
Drupal
Magento
custom PHP
```
and many other PHP applications.

62. One PHP-FPM Pool Can Serve Multiple Sites

A basic server might use:
```
Nginx
 │
 └── PHP-FPM www pool
      ├── site1
      ├── site2
      └── site3
```
This is simple.

But for stronger isolation, separate pools/users can be used.

63. Multi-Tenant Hosting

This becomes important for your hosting platform.

Imagine:
```
CresignSys Hosting
│
├── Customer A
├── Customer B
├── Customer C
└── Customer D
```
You don’t necessarily want all customers’ PHP applications running with exactly the same privileges.

A stronger architecture might be:
```
Customer A
 ↓
PHP-FPM pool A
 ↓
user A

Customer B
 ↓
PHP-FPM pool B
 ↓
user B
```
64. Why Separate Users Matter

Suppose:
```
Customer A
```
has a vulnerable plugin.

If A’s PHP process runs as:
```
customerA
```
then Linux permissions can limit access to:
```
customerA's files
```
instead of:
```
all customer websites
```
This is an important multi-tenant security principle.

65. Shared www-data Model

A simpler model:
```
site A → www-data
site B → www-data
site C → www-data
```
is easier to manage.

But isolation is weaker.

A compromise of one application running under the same account can potentially access files writable/readable by that shared account.

66. Isolated Pool Model

A more isolated model:
```
site A → php-fpm pool A → userA
site B → php-fpm pool B → userB
site C → php-fpm pool C → userC
```
gives more control.

It is more complex to configure and manage.

67. This Is Where Hosting Panels Become Useful

Hosting panels automate:
```
User creation
Website creation
PHP-FPM pools
Nginx configuration
Permissions
SSL
Logs
Databases
Backups
```
Your CresignSys Hosting Platform is essentially moving toward building these capabilities yourself.

68. PHP-FPM Logs

Check service logs with:
```
sudo journalctl -u php8.3-fpm
```
For recent entries:
```
sudo journalctl -u php8.3-fpm -n 100
```
Replace the version with yours.

69. Follow Logs Live
```
sudo journalctl -u php8.3-fpm -f
```
Then make a website request.

You can observe whether PHP-FPM reports errors.

70. Nginx + PHP-FPM Debugging

If you receive:
```
502 Bad Gateway
```
use this sequence:
```
1. Is Nginx running?
2. Is PHP-FPM running?
3. Does the socket exist?
4. Does Nginx point to the correct socket?
5. Can Nginx connect to the socket?
6. Are socket permissions correct?
7. Does PHP-FPM report errors?
```
71. Check Service
```
systemctl status php8.3-fpm
```
72. Check Socket
```
ls -l /run/php/
```
73. Check Nginx Configuration
```
sudo nginx -T | grep -n fastcgi_pass
```
74. Check Nginx Errors
```
sudo tail -f /var/log/nginx/error.log
```
75. Check PHP-FPM Errors
```
sudo journalctl -u php8.3-fpm -f
```
76. This Gives a Complete Diagnostic Chain
```
Browser
   ↓
HTTP 502
   ↓
Nginx
   ↓
error.log
   ↓
PHP-FPM
   ↓
journalctl
   ↓
socket
   ↓
Linux permissions
```
Instead of randomly changing configuration, you identify the failing layer.

77. Test PHP Directly

Create a temporary test file only when needed and remove it afterward:
```
<?php
phpinfo();
```
For example:
```
/storage/websites/example.com/public/test.php
```
Then visit:
```
https://example.com/test.php
```
This shows the PHP environment used by the website.

78. Security Warning

phpinfo() exposes extensive environment information.

Do not leave it publicly accessible.

After testing:
```
rm /storage/websites/example.com/public/test.php
```
79. Better: Temporary Diagnostic Endpoint

For production environments, prefer safer diagnostics rather than leaving phpinfo() publicly available.

The principle is:
```
diagnostic information
 ↓
temporary
 ↓
restricted
 ↓
removed after use
```
80. PHP Version

Different PHP versions can behave differently.

For example:
```
PHP 8.1
PHP 8.2
PHP 8.3
PHP 8.4
```
Applications and plugins may have compatibility requirements.

Therefore a hosting platform must manage PHP versions carefully.

81. Multiple PHP Versions

A server can potentially have:
```
PHP 8.1
PHP 8.2
PHP 8.3
PHP 8.4
```
with different FPM services:
```
php8.1-fpm
php8.2-fpm
php8.3-fpm
php8.4-fpm
```
Then different websites can use different versions.

82. Example
```
siteA.com
 ↓
PHP 8.2 FPM

siteB.com
 ↓
PHP 8.3 FPM

siteC.com
 ↓
PHP 8.4 FPM
```
Nginx determines which PHP-FPM endpoint each website uses.

83. Why Hosting Providers Offer PHP Versions

Customers may have applications that require:
```
specific PHP version
```
A hosting platform therefore often offers:
```
PHP version selector
```
This is a significant feature for a commercial hosting system.

84. PHP Lifecycle

PHP versions eventually reach:
```
Active support
 ↓
Security support
 ↓
End of life
```
A hosting platform should avoid encouraging unsupported PHP versions unless there is a specific legacy requirement and appropriate risk management.

85. WordPress Compatibility

WordPress itself, themes, and plugins can have different compatibility requirements.

Therefore changing:
```
PHP 8.2 → 8.4
```
should be tested rather than done blindly on production websites.

86. PHP-FPM Is a Process Manager

Remember the full meaning:
```
PHP
=
language/runtime

FastCGI
=
communication protocol/interface

FPM
=
process manager
```
Together:
```
PHP-FPM
=
managed PHP execution through FastCGI
```
87. Deep Request Architecture

Now our architecture is:
```
Browser
   │
   ▼
HTTPS
   │
   ▼
Nginx
   │
   │ FastCGI
   ▼
PHP-FPM master
   │
   ▼
PHP worker
   │
   ▼
WordPress
   │
   ▼
MySQL
```
And the filesystem/security layer:
```
PHP worker
   │
   ▼
Linux user
   │
   ▼
Linux kernel
   │
   ▼
Filesystem
```
88. The Most Important Concepts

Memorize these:
```
PHP
=
server-side programming language/runtime

PHP-FPM
=
PHP process manager

FastCGI
=
communication mechanism between Nginx and PHP-FPM

Pool
=
group of PHP workers

Worker
=
process that executes PHP requests

Socket
=
communication endpoint

OPcache
=
compiled PHP bytecode cache

php.ini
=
PHP configuration

pm.max_children
=
maximum child workers for a pool
```
89. One Complete WordPress Request

Let’s put everything together.

User requests:
```
https://templates.cresignsys.com/about/
```
DNS
```
domain
 ↓
IP
```
TCP
```
client
 ↓
server:443
```
TLS
```
secure channel
```
HTTP
```
GET /about/
Host: templates.cresignsys.com
```
Nginx
```
server_name
 ↓
location /
 ↓
try_files
```
PHP-FPM
```
FastCGI
 ↓
PHP worker
```
WordPress
```
load WordPress
 ↓
plugins
 ↓
theme
 ↓
database
```
MySQL
```
query
 ↓
result
```
PHP
```
generate HTML
```
Nginx
```
send response
```
TLS
```
encrypt response
```
Browser
```
decrypt
 ↓
parse HTML
 ↓
render page
```
90. The Full Hosting Stack

You can now visualize your server as:
```
                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP/Route
                            │
                            ▼
                        TCP / QUIC
                            │
                            ▼
                           TLS
                            │
                            ▼
                          HTTP
                            │
                            ▼
                          NGINX
                            │
                 ┌──────────┴──────────┐
                 │                     │
                 ▼                     ▼
             Static files          FastCGI
                                       │
                                       ▼
                                  PHP-FPM
                                       │
                                  ┌────┴────┐
                                  ▼         ▼
                               Worker 1   Worker 2
                                  │
                                  ▼
                              WordPress
                                  │
                                  ▼
                                MySQL
                                  │
                                  ▼
                              Filesystem
                                  │
                                  ▼
                             Linux Kernel
                                  │
                         ┌────────┴────────┐
                         ▼                 ▼
                        RAM               Disk
```
This is the core architecture of a traditional PHP WordPress hosting environment.

Lesson 044 Summary

The most important idea:

Nginx receives the web request; PHP-FPM provides managed PHP execution; WordPress is the PHP application.

The relationship is:
```
Nginx
  ↓
FastCGI
  ↓
PHP-FPM
  ↓
PHP worker
  ↓
WordPress
  ↓
MySQL
```
And PHP-FPM’s resources are controlled through:
```
workers
pools
memory
CPU
sockets
timeouts
PHP configuration
OPcache
```
For your own hosting platform, this is the layer where website performance, PHP version selection, resource limits, and multi-tenant isolation become major design considerations.

Next Lesson — 045

MySQL From the Absolute Basics — How WordPress Stores Everything

We will start from:
```
What is data?
What is a database?
What is SQL?
What is MySQL?
What is a table?
What is a row?
What is a column?
What is a primary key?
What is an index?
```
Then connect it directly to WordPress:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ├── wp_posts
 ├── wp_users
 ├── wp_options
 ├── wp_postmeta
 ├── wp_terms
 └── wp_usermeta
```
and trace exactly what happens inside MySQL when you create a WordPress page, user, plugin, menu, or post.
August 13, 2026
CresignSys Learn — Lesson 043
Linux Filesystem & Permissions — The Foundation of Web Hosting

We now move below Nginx and PHP-FPM.

A web server ultimately depends on the Linux operating system being able to answer:

Who is allowed to read, write, execute, create, delete, and access this file?

For your hosting system, this is fundamental.

1. The Hosting Stack So Far

We have reached:
```
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
Now go one layer deeper:
```
PHP-FPM
   ↓
Linux filesystem
   ↓
Storage
```
2. Linux Is a Filesystem-Centered System

Linux represents many things through files or filesystem interfaces.

You will constantly work with:
```
/
├── etc/
├── var/
├── home/
├── usr/
├── run/
├── tmp/
└── storage/
```
The first:
```
/
```
is called:

Root directory

It is the top of the Linux filesystem hierarchy.

3. / Is Not /root

These are completely different.
```
/
```
means:

filesystem root

while:
```
/root
```
means:

home directory of the root user

This distinction is very important.

4. Your Website Path

Your hosting structure has looked like:
```
/storage/websites/
```
Inside:
```
/storage/websites/
├── domain1.com/
├── domain2.com/
└── domain3.com/
```
Each domain can have its own directory.

5. Example

Suppose:
```
/storage/websites/templates.cresignsys.com/public/
```
contains:
```
public/
├── index.php
├── wp-admin/
├── wp-content/
├── wp-includes/
└── wp-config.php
```
This is your WordPress document root.

6. Path

A path identifies where something exists.

For example:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
Break it down:
```
/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public
                └── index.php
```
7. Absolute Path

A path beginning with:
```
/
```
is an absolute path.

Example:
```
/storage/websites/templates.cresignsys.com/public
```
It starts from filesystem root.

8. Relative Path

A relative path depends on your current directory.

If you are inside:
```
/storage/websites/templates.cresignsys.com/
```
then:
```
public/index.php
```
refers to:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
9. pwd

To find your current directory:
```
pwd
```
Example:
```
/storage/websites/templates.cresignsys.com/public
```
pwd means:

Print Working Directory

10. ls

To see files:
```
ls
```
More detailed:
```
ls -l
```
Including hidden files:
```
ls -la
```
11. Example ls -l

You may see:
```
-rw-r--r-- 1 www-data www-data 1234 Aug 13 index.php
```
This line contains a lot of information.

Let’s decode it.

12. First Character
```
-rw-r--r--
^
```
The first character tells you the object type.

Common examples:
```
-
```
regular file.
```
d
```
directory.
```
l
```
symbolic link.

So:
```
-rw-r--r--
```
is a regular file.

13. Permission Characters

After the first character:
```
rw-r--r--
```
There are three groups:
```
rw-
r--
r--
```
These correspond to:
```
Owner
Group
Others
```
14. Read
```
r
```
means:

Read

For a file, read means the process can read its contents.

For a directory, read has a different meaning: it allows listing directory entries, subject to other permissions.

15. Write
```
w
```
means:

Write

For a file:
```
w
```
allows modifying its contents.

For a directory, write is related to creating, deleting, and renaming entries within it.

16. Execute
```
x
```
means:

Execute

For an ordinary executable file, it allows execution.

For a directory, x means the process can traverse/access entries within that directory, subject to other permissions.

This distinction is extremely important for web hosting.

17. Three Permission Groups

Consider:
```
rw-r--r--
```
Break it:
```
rw- | r-- | r--
 │     │     │
 │     │     └── Others
 │     └──────── Group
 └────────────── Owner
```
18. Example
```
-rw-r--r--
```
means:
```
Owner:
rw-

Group:
r--

Others:
r--
```
So:
```
Owner → read + write
Group → read
Others → read
```
19. Numeric Permissions

Linux also represents permissions numerically.

The values are:
```
r = 4
w = 2
x = 1
```
Add them.

20. 7
```
rwx
```
means:
```
4 + 2 + 1 = 7
```
21. 6
```
rw-
```
means:
```
4 + 2 = 6
```
22. 5
```
r-x
```
means:
```
4 + 1 = 5
```
23. 4
```
r--
```
means:
```
4
```
24. 0
```
---
```
means:
```
0
```
25. 755

A very common directory permission:
```
755
```
means:
```
Owner:
7 = rwx

Group:
5 = r-x

Others:
5 = r-x
```
So:
```
rwxr-xr-x
```
26. 644

A common file permission:
```
644
```
means:
```
Owner:
6 = rw-

Group:
4 = r--

Others:
4 = r--
```
Therefore:
```
rw-r--r--
```
27. Why 644 Is Common for Files

A normal web file such as:
```
index.php
style.css
logo.png
```
usually needs to be readable by the web server.

It doesn’t normally need to be executable as a Unix program.

Therefore:
```
644
```
is often appropriate.

But permissions must always be determined from the actual application and deployment model.

28. Why 755 Is Common for Directories

A directory generally needs:
```
r
```
to list entries and:
```
x
```
to traverse it.

A common configuration is:
```
755
```
allowing the owner full access and others read/traverse access.

Again, the correct permissions depend on the application.

29. Owner

Now consider:
```
-rw-r--r-- 1 www-data www-data index.php
```
The first:
```
www-data
```
is the owner.

The second:
```
www-data
```
is the group.

30. User

Linux identifies users.

Examples:
```
root
ubuntu
www-data
```
Each has a user ID.

The kernel uses these identities when enforcing permissions.

31. Group

A user can belong to one or more groups.

Groups allow permissions to be shared among multiple users/processes.

For example:
```
webadmins
```
could contain administrators who need access to website files.

32. Root

root is the superuser.

Conceptually:
```
root
 ↓
very high system privileges
```
Root can bypass many ordinary filesystem permission restrictions.

That power must be used carefully.

33. sudo

If you are logged in as:
```
ubuntu
```
you may use:
```
sudo command
```
to execute a command with elevated privileges if your account is authorized.

For example:
```
sudo systemctl reload nginx
```
34. Why sudo Matters

Changing:
```
/etc/nginx/
```
usually requires elevated privileges.

But editing your website’s own files may not require root.

A good principle is:

Use the minimum privileges required for the task.

35. www-data

On Debian/Ubuntu web servers, services such as Nginx and PHP-FPM commonly use:
```
www-data
```
as their service user, though the exact configuration should be checked.

36. Why www-data Matters

Suppose:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
```
and PHP-FPM runs as:
```
www-data
```
Then PHP processes access files as that Linux user.

Therefore:
```
PHP-FPM
 ↓
Linux permissions
 ↓
website files
```
37. WordPress Needs Write Access

WordPress may need to write files for things such as:
```
uploads
plugin installation
theme installation
updates
generated cache files
temporary files
```
Whether WordPress should have write access to all of the site is a security/design decision.

Giving the entire WordPress tree broad write access is generally undesirable.

38. Security Principle

Don’t simply do:
```
chmod -R 777 /storage/websites/example.com
```
This is a major mistake.

777 means:
```
Owner  = rwx
Group  = rwx
Others = rwx
```
Everyone gets broad read/write/execute access.

39. Why 777 Is Dangerous

Imagine an attacker finds a vulnerability in a website.

If everything is writable:
```
Attacker
 ↓
Web application vulnerability
 ↓
Write anywhere
 ↓
Upload/modify files
 ↓
Persistence
```
The impact can become much worse.

40. Principle of Least Privilege

A fundamental security principle:

Give a process only the permissions it actually needs.

For example:
```
Static assets
 ↓
read-only for web server
```
while:
```
wp-content/uploads
 ↓
write access where needed
```
This creates a smaller attack surface.

41. Directory Permissions Are Different

Suppose:
```
drwxr-xr-x
```
The x on a directory means:

Can traverse this directory.

Without directory execute permission, even if a user can read the directory listing, access to files inside can still fail.

42. Example

Imagine:
```
/storage
   ↓
/websites
   ↓
/example.com
   ↓
/public
```
The web-service user needs appropriate traversal permissions through every parent directory.

If one parent directory blocks traversal:
```
/storage
   ↓
permission denied
```
Nginx may fail to serve the website.

43. chmod

chmod changes permissions.

Example:
```
chmod 644 index.php
```
or:
```
chmod 755 public
```
44. Symbolic Permissions

Instead of:
```
chmod 644 file
```
you can use:
```
chmod u=rw,g=r,o=r file
```
This means:
```
u = user/owner
g = group
o = others
```
45. chown

chown changes ownership.

Example:
```
sudo chown www-data:www-data index.php
```
This sets:
```
owner = www-data
group = www-data
```
46. chgrp

chgrp changes the group without changing the owner.

Example:
```
sudo chgrp webadmins file.txt
```
47. Ownership vs Permissions

Don’t confuse these.

Ownership answers:
```
Who owns this?
```
Permissions answer:
```
What can the owner/group/others do?
```
48. Example

Suppose:
```
-rw-r----- 
root webadmins
```
Then:
```
Owner:
root → read/write

Group:
webadmins → read

Others:
no access
```
49. id

To see your current user and groups:
```
id
```
Example:
```
uid=1000(ubuntu) gid=1000(ubuntu) groups=...
```
50. Check www-data

You can inspect:
```
id www-data
```
This tells you the user ID and group memberships.

51. Find Nginx User

Inspect Nginx configuration:
```
grep -n "user " /etc/nginx/nginx.conf
```
You may see something like:
```
user www-data;
```
52. Find PHP-FPM User

The PHP-FPM pool configuration determines the worker user.

Depending on PHP version, inspect:
```
grep -R "^[[:space:]]*user[[:space:]]*=" /etc/php/*/fpm/pool.d/
```
and:
```
grep -R "^[[:space:]]*group[[:space:]]*=" /etc/php/*/fpm/pool.d/
```
You may see:
```
user = www-data
group = www-data
```
53. Nginx and PHP-FPM May Both Use www-data

A common architecture is:
```
Nginx
 ↓
www-data

PHP-FPM
 ↓
www-data
```
This simplifies access to website files.

But it also means you should carefully design write permissions.

54. Website Directory Design

A clean hosting structure could be:
```
/storage/websites/
│
├── example.com/
│   ├── public/
│   ├── logs/
│   └── private/
│
├── shop.example.com/
│   ├── public/
│   ├── logs/
│   └── private/
│
└── learn.example.com/
    ├── public/
    ├── logs/
    └── private/
```
The key principle is:
```
public/
=
web-accessible area
```
55. Public vs Private

Suppose:
```
/storage/websites/example.com/public/
```
is Nginx’s document root.

Anything inside this directory may potentially be served through HTTP if the Nginx configuration permits it.

Therefore don’t put secrets there.

56. Dangerous Files

Never intentionally expose things such as:
```
.env
private keys
database backups
SSH keys
application secrets
configuration credentials
```
through the public document root.

57. WordPress wp-config.php

WordPress has:
```
wp-config.php
```
which may contain database credentials and security secrets.

Therefore:
```
public/wp-config.php
```
must be protected by the web-server/application architecture.

Modern WordPress/Nginx setups generally prevent direct source disclosure of PHP files because PHP is executed rather than served as plain text, but defense-in-depth still matters.

58. PHP Source Must Not Be Downloadable

If a PHP file were accidentally served as:
```
text/plain
```
instead of being processed by PHP-FPM, its source code could be exposed.

Correct architecture:
```
.php
 ↓
Nginx
 ↓
PHP-FPM
 ↓
execute
```
not:
```
.php
 ↓
Browser downloads source
```
59. Permissions and WordPress

A typical security-oriented approach is:
```
WordPress core
 ↓
mostly read-only

Uploads/cache areas
 ↓
writeable as required
```
The exact strategy depends on how you administer WordPress.

60. Linux File Permissions Are Not the Only Layer

A file can be restricted by:
```
Unix permissions
+
ACLs
+
SELinux/AppArmor
+
Nginx rules
+
PHP-FPM restrictions
+
filesystem mount options
```
Ubuntu commonly uses AppArmor for some services.

61. ACL

ACL means:

Access Control List

ACLs can provide permissions beyond the simple:
```
owner
group
others
```
model.

For example:
```
user A → read/write
user B → read
group C → read
```
on the same file.

62. getfacl

To inspect ACLs:
```
getfacl file.txt
```
If your server doesn’t use custom ACLs, the output may closely resemble normal permissions.

63. setfacl

ACLs can be changed with:
```
setfacl
```
But don’t introduce ACL complexity unless you actually need it.

For a hosting platform, simple ownership/groups are often easier to maintain.

64. Symbolic Links

You may see:
```
lrwxrwxrwx
```
The first character:
```
l
```
means:

Symbolic link

A symbolic link points to another path.

65. Let’s Encrypt Uses Links

This is particularly relevant to your server.

Certbot commonly maintains:
```
/etc/letsencrypt/live/domain/
```
with symbolic links to files under:
```
/etc/letsencrypt/archive/domain/
```
Conceptually:
```
live/
 ↓
symbolic link
 ↓
archive/
```
This is one reason you should not casually delete or replace those files manually.

66. Inspect the Links

Run:
```
sudo ls -la /etc/letsencrypt/live/templates.cresignsys.com/
```
You may see entries similar to:
```
cert.pem -> ../../archive/.../cert1.pem
chain.pem -> ../../archive/.../chain1.pem
fullchain.pem -> ../../archive/.../fullchain1.pem
privkey.pem -> ../../archive/.../privkey1.pem
```
The exact numbering can vary.

67. Why live/ Exists

Certbot can maintain stable paths:
```
/etc/letsencrypt/live/domain/fullchain.pem
```
while the actual versioned certificate files live elsewhere.

Nginx can keep referencing the stable path.

When renewal occurs, the links can be updated to the latest version.

68. Certificate Renewal Connection

Now connect the filesystem lesson to TLS:
```
Certbot
 ↓
new certificate
 ↓
/etc/letsencrypt/archive/
 ↓
updates /live/ links
 ↓
Nginx reload
 ↓
new certificate used
```
This is why file permissions and symlinks matter to SSL automation.

69. ls -l Is a Core Skill

You should become comfortable reading:
```
ls -la
```
because it tells you:
```
file type
permissions
owner
group
size
timestamp
name
symlink target
```
70. stat

For deeper information:
```
stat index.php
```
You can see:
```
File
Size
Blocks
IO Block
Device
Inode
Links
Access
Uid
Gid
Access time
Modify time
Change time
```
71. Inode

Every filesystem object has an:

inode

The inode stores metadata associated with a filesystem object.

Conceptually:
```
Filename
   ↓
directory entry
   ↓
inode
   ↓
metadata + file data references
```
72. Filename vs Inode

A filename isn’t the file’s entire identity internally.

The filesystem maintains a relationship:
```
directory
   ↓
name → inode
```
This explains concepts such as hard links.

73. Hard Link

A hard link is another directory entry referring to the same inode.

Conceptually:
```
file1
  │
  ▼
inode 123

file2
  │
  ▼
inode 123
```
Both names refer to the same underlying inode.

74. Symbolic Link

A symbolic link is different:
```
link
 ↓
path to another object
```
It doesn’t point directly to the target inode in the same way a hard link does.

75. Why This Matters to Hosting

You will encounter symbolic links in:
```
Let's Encrypt
PHP configurations
Nginx configurations
Application deployments
Release management
```
Understanding them prevents many mistakes.

76. Disk Space

Website files ultimately consume storage.

Check:
```
df -h
```
This shows filesystem capacity.

Example:
```
Filesystem
Size
Used
Avail
Use%
Mounted on
```
77. Directory Size

To inspect a website:
```
du -sh /storage/websites/templates.cresignsys.com
```
For more detail:
```
du -sh /storage/websites/templates.cresignsys.com/*
```
This helps identify what is consuming disk space.

78. Disk vs Inode Exhaustion

A server can have free disk space but still run out of inodes.

Check:
```
df -i
```
This is particularly relevant to hosting servers with huge numbers of small files.

79. Why Hosting Servers Can Have Many Files

WordPress can contain:
```
Core files
Plugins
Themes
Uploads
Cache
Logs
Temporary files
```
A server hosting hundreds of sites can therefore contain millions of filesystem objects.

80. Permissions + Storage + Nginx

A web request ultimately becomes:
```
HTTP
 ↓
Nginx
 ↓
Filesystem
 ↓
Linux kernel
 ↓
Permission check
 ↓
Disk
```
The kernel decides whether the Nginx/PHP process is allowed to perform the operation.

81. Linux Kernel Is the Authority

This is a deep concept.

Nginx does not decide:

www-data is allowed to read this file.

The Linux kernel enforces filesystem access.

Conceptually:
```
Nginx process
 ↓
system call
 ↓
Linux kernel
 ↓
permission check
 ↓
filesystem
```
82. System Call

Programs interact with the kernel through system calls.

For example, a program may request:
```
open file
read file
write file
```
The kernel decides whether the operation is permitted.

83. Example

Nginx wants:
```
read:
/storage/websites/example.com/public/index.html
```
Conceptually:
```
Nginx
 ↓
open()
 ↓
Linux kernel
 ↓
check permissions
 ↓
allow/deny
```
If denied:
```
Permission denied
```
84. This Explains 403

Suppose Nginx receives:
```
GET /secret.html
```
but cannot read the file.

The result may become:
```
403 Forbidden
```
depending on the configuration and exact reason.

85. This Explains PHP Errors Too

Suppose PHP-FPM tries to write:
```
wp-content/uploads/
```
but doesn’t have permission.

Then:
```
WordPress
 ↓
PHP-FPM
 ↓
Linux permission check
 ↓
DENIED
```
WordPress may report an upload or filesystem error.

86. Three Different Users

On your server you might have:
```
ubuntu
root
www-data
```
They serve different purposes.

ubuntu

Administrative login user.

root

System superuser.

www-data

Web-service/application user.

The exact users on your system should be verified.

87. Why Don’t Run Everything as Root?

If PHP-FPM ran as root:
```
PHP vulnerability
 ↓
attacker
 ↓
root privileges
 ↓
potential full server compromise
```
Running services with restricted privileges limits the potential impact.

88. Security Model

A strong hosting architecture tries to separate:
```
Administrator
     ↓
root/sudo

Web server
     ↓
limited service user

Database
     ↓
database-specific account

Website
     ↓
restricted filesystem permissions
```
89. Database User Is Separate

WordPress doesn’t normally connect to MySQL as Linux root.

It uses database credentials stored in its configuration.

Conceptually:
```
WordPress
 ↓
MySQL credentials
 ↓
MySQL user
 ↓
specific database
```
This is another layer of least privilege.

90. Linux User vs MySQL User

Don’t confuse:
```
Linux:
www-data
```
with:
```
MySQL:
wordpress_user
```
They belong to different security systems.

91. Complete Security Boundary

Your website now has several independent layers:
```
Internet
 ↓
Cloud firewall
 ↓
Ubuntu networking
 ↓
Nginx
 ↓
TLS
 ↓
Linux user
 ↓
Filesystem permissions
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL user
 ↓
Database permissions
```
92. Practical Inspection

For your website, start with:
```
ls -ld /storage
ls -ld /storage/websites
ls -ld /storage/websites/templates.cresignsys.com
ls -ld /storage/websites/templates.cresignsys.com/public
```
This shows directory permissions and ownership at every level.

93. Inspect WordPress Files
```
ls -la /storage/websites/templates.cresignsys.com/public
```
Look for:
```
index.php
wp-config.php
wp-admin/
wp-content/
wp-includes/
```
94. Inspect Ownership
```
sudo stat /storage/websites/templates.cresignsys.com/public/index.php
```
Look for:
```
Uid
Gid
Access
```
95. Test Access as www-data

A very useful diagnostic:
```
sudo -u www-data ls \
/storage/websites/templates.cresignsys.com/public
```
This asks:

Can the www-data user actually list this directory?

96. Test Reading a File
```
sudo -u www-data cat \
/storage/websites/templates.cresignsys.com/public/index.php
```
If permission is denied, you have identified a filesystem-access problem.

Be careful with commands that print sensitive configuration files such as wp-config.php.

97. Test Directory Traversal

You can inspect each parent:
```
namei -l /storage/websites/templates.cresignsys.com/public/index.php
```
This is an excellent command.

It shows permissions/ownership along the entire path.

98. Why namei Is Powerful

Suppose:
```
/storage
```
is inaccessible to www-data.

Even if:
```
public/index.php
```
has:
```
644
```
Nginx may still fail.

namei -l helps find the exact blocking directory.

99. The Practical Permission Model

A useful starting principle for a typical WordPress hosting setup is:
```
Directories
≈ 755

Files
≈ 644
```
but don’t blindly apply these recursively to every file.

Sensitive files and writable directories may need different permissions.

100. Never Blindly Run Recursive Permission Commands

Avoid blindly doing:
```
chmod -R 777 ...
```
or:
```
chown -R www-data:www-data /
```
The second could be catastrophic.

Always specify the exact website directory and understand what you’re changing.

101. Your Hosting Platform

For your CresignSys Hosting Platform, a better model is:
```
/storage/websites/
│
├── site1/
│   ├── public/
│   ├── logs/
│   └── private/
│
├── site2/
│   ├── public/
│   ├── logs/
│   └── private/
│
└── site3/
    ├── public/
    ├── logs/
    └── private/
```
Then your automation can consistently create:
```
directory
ownership
permissions
Nginx configuration
PHP-FPM configuration
SSL configuration
logs
```
102. Hosting Automation Flow

Eventually your hosting-create script can do:
```
Create domain
     ↓
Create directories
     ↓
Set ownership
     ↓
Set permissions
     ↓
Create Nginx config
     ↓
Test Nginx
     ↓
Reload Nginx
     ↓
Create DNS record
     ↓
Issue Let's Encrypt certificate
     ↓
Install certificate
     ↓
Configure HTTPS
     ↓
Install WordPress
```
You are now learning the individual layers behind that automation.

103. Deep Architecture

We can now expand the stack:
```
                    INTERNET
                       │
                       ▼
                      DNS
                       │
                       ▼
                    ROUTING
                       │
                       ▼
                    TCP/UDP
                       │
                       ▼
                      TLS
                       │
                       ▼
                      HTTP
                       │
                       ▼
                     NGINX
                       │
                ┌──────┴──────┐
                ▼             ▼
           FILESYSTEM      PHP-FPM
                              │
                              ▼
                          WORDPRESS
                              │
                              ▼
                            MYSQL
                              │
                              ▼
                          STORAGE
```
And underneath everything:
```
Linux Kernel
     ↓
CPU
     ↓
RAM
     ↓
Disk/Storage
     ↓
Network Interface
```
104. The Next Level

We have now reached an important boundary.

We understand:
```
DNS
IP
TCP
TLS
HTTP
Nginx
Filesystem
Permissions
```
The next major component is:

PHP-FPM

because this is the bridge between:
```
Nginx
```
and:
```
WordPress
```
Lesson 043 Summary

The most important concepts are:
```
Path
=
location of a filesystem object

Owner
=
user associated with the object

Group
=
group associated with the object

Permissions
=
read/write/execute rules

www-data
=
common web-service user

root
=
superuser

chmod
=
change permissions

chown
=
change ownership

sudo
=
execute with elevated privileges

inode
=
filesystem metadata/object identifier

symlink
=
link pointing to another path
```
For your hosting server:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Linux kernel
 ↓
Filesystem
```
Linux permissions determine whether those processes can actually access the files they need.

Next Lesson — 044

PHP-FPM From Zero — How PHP Actually Runs on Your Server

We will trace:
```
Browser
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP worker process
 ↓
WordPress
 ↓
MySQL
```
and go deeply into:
```
PHP
PHP-FPM
FPM pools
workers
Unix sockets
FastCGI
php.ini
memory limits
execution limits
OPcache
PHP versions
PHP 8.x
process management
www-data
security isolation
```
This is the next major foundation for understanding why WordPress hosting works.
August 13, 2026
CresignSys Learn — Lesson 042
Nginx From Zero: How a Web Server Actually Processes a Request

We now move from HTTP theory into the actual technology running your websites.

Your architecture is approximately:
```
Browser
   ↓
DNS
   ↓
Internet
   ↓
Ubuntu VPS
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
```
Today we focus almost entirely on:

Nginx

1. What Is Nginx?

Nginx is a high-performance web server and reverse proxy.

It can perform several jobs:
```
Nginx
│
├── Web server
├── TLS endpoint
├── Reverse proxy
├── HTTP router
├── Static-file server
├── Load balancer
└── Access-control layer
```
For your hosting platform, the most important roles initially are:
```
HTTP server
+
TLS termination
+
Static file server
+
PHP-FPM gateway
```
2. Nginx Is Not PHP

This distinction is fundamental.
```
Nginx
=
web server
```
while:
```
PHP-FPM
=
PHP application execution manager
```
and:
```
WordPress
=
PHP application
```
So:
```
Browser
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
```
3. Nginx Does Not Normally Execute PHP

Suppose the browser requests:
```
/wp-login.php
```
Nginx doesn’t normally interpret PHP itself.

Instead:
```
Browser
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP interpreter
```
4. Nginx Can Serve Static Files Directly

Suppose the browser requests:
```
/logo.png
```
Nginx can do:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
logo.png
 ↓
Browser
```
No PHP needed.

5. Why This Is Efficient

Imagine your website contains:
```
logo.png
style.css
script.js
font.woff2
```
These are static resources.

There is no reason to start WordPress for every one of them.

Nginx can serve them directly.

6. Nginx Configuration

Nginx is controlled through configuration files.

A common main configuration is:
```
/etc/nginx/nginx.conf
```
Additional configurations may be included from directories such as:
```
/etc/nginx/conf.d/
```
and on Debian/Ubuntu systems commonly:
```
/etc/nginx/sites-available/
/etc/nginx/sites-enabled/
```
Your exact installation may use a custom structure.

7. Configuration Is Text

Nginx configuration is declarative.

Example:
```
server {
    listen 80;
    server_name example.com;

    root /var/www/example;
}
```
This tells Nginx how to handle requests.

8. server {}

The fundamental Nginx virtual-host structure is:
```
server {
    ...
}
```
A server block defines a virtual server.

Think:
```
server {}
=
one website/server configuration
```
9. Multiple Websites

You can have:
```
server {
    server_name site1.com;
}

server {
    server_name site2.com;
}

server {
    server_name site3.com;
}
```
All can potentially run on the same machine/IP.

This is the foundation of multi-domain hosting.

10. listen

Example:
```
listen 80;
```
means Nginx listens for HTTP traffic on port 80.

For HTTPS:
```
listen 443 ssl;
```
means the server handles TLS/HTTPS traffic on port 443.

Modern Nginx configurations can express TLS settings in different ways depending on version and configuration style.

11. Port 80 vs 443

Remember:
```
80
 ↓
HTTP

443
 ↓
HTTPS/TLS
```
A common architecture is:
```
HTTP :80
    ↓
301/308 redirect
    ↓
HTTPS :443
```
12. server_name

Example:
```
server_name templates.cresignsys.com;
```
This associates the server block with the hostname.

So:
```
templates.cresignsys.com
        ↓
Nginx
        ↓
matching server block
```
13. root

Example:
```
root /storage/websites/templates.cresignsys.com/public;
```
This tells Nginx the filesystem root for static resources in that server context.

So:
```
/logo.png
```
can correspond conceptually to:
```
/storage/websites/templates.cresignsys.com/public/logo.png
```
14. Important: URL ≠ Filesystem

A request:
```
/about/
```
doesn’t necessarily mean:
```
/storage/.../about/
```
The mapping depends on Nginx configuration and potentially application routing.

This becomes very important with WordPress.

15. location

Nginx uses:
```
location / {
    ...
}
```
to determine how a URI should be processed.

Think:
```
URL path
   ↓
location matching
   ↓
processing rules
```
16. Basic Location

Example:
```
location / {
    try_files $uri $uri/ /index.php?$args;
}
```
This is a common WordPress pattern.

It means approximately:
```
Try requested file
        ↓
If not found, try directory
        ↓
Otherwise send request to WordPress
```
17. try_files

This directive is extremely important for WordPress.

Example:
```
try_files $uri $uri/ /index.php?$args;
```
Conceptually:
```
Request /about/

        ↓

Does file exist?
        ↓
      NO

Does directory exist?
        ↓
      maybe

Otherwise:
        ↓
/index.php
```
18. Why WordPress Needs This

WordPress uses:

Pretty URLs

For example:
```
/about/
/contact/
/services/website-hosting/
```
There may be no physical file:
```
/about/index.html
```
Instead WordPress handles the route.

19. WordPress Front Controller

WordPress commonly uses:
```
index.php
```
as a central entry point.

Conceptually:
```
Request
 ↓
Nginx
 ↓
index.php
 ↓
WordPress
 ↓
Routing
 ↓
Page
```
This architecture is often called a:

Front controller

20. Example

Browser requests:
```
/about/
```
Nginx:
```
Does /about/ exist?
```
Suppose no physical file exists.

Then:
```
/index.php
```
is used.

WordPress receives:
```
/about/
```
through the request environment and determines what content to generate.

21. PHP Location

A typical Nginx configuration contains something conceptually like:
```
location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
```
The exact PHP version/socket on your server must be checked.

22. What Does ~ \.php$ Mean?

This is a regular-expression location.

It roughly matches URI paths ending in:
```
.php
```
For example:
```
/index.php
/wp-login.php
/wp-cron.php
```
23. FastCGI

Nginx communicates with PHP-FPM using:

FastCGI

Conceptually:
```
Nginx
  │
  │ FastCGI
  ▼
PHP-FPM
```
FastCGI is a protocol/interface for passing requests to application processes.

24. PHP-FPM Socket

On Ubuntu, PHP-FPM may listen through a Unix socket such as:
```
/run/php/php8.1-fpm.sock
```
or another version:
```
/run/php/php8.3-fpm.sock
```
The exact path depends on your installed PHP version/configuration.

25. Unix Socket

A Unix socket is a local IPC mechanism.

IPC means:

Inter-Process Communication

Instead of:
```
Nginx
 ↓
Internet
 ↓
PHP-FPM
```
both processes communicate locally:
```
Nginx
 │
 │ Unix socket
 ▼
PHP-FPM
```
26. Why Use a Unix Socket?

For services on the same server, a Unix socket can provide an efficient local communication mechanism.

Another possibility is TCP:
```
127.0.0.1:9000
```
Both approaches are common.

27. fastcgi_pass

Example:
```
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
```
means:

Send the FastCGI request to this PHP-FPM endpoint.

28. SCRIPT_FILENAME

One particularly important parameter is:
```
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
```
It tells PHP-FPM which actual filesystem script should be executed.

For example:
```
Document root:
/storage/websites/templates.cresignsys.com/public

Script:
index.php
```
becomes approximately:
```
/storage/websites/templates.cresignsys.com/public/index.php
```
29. The Complete PHP Request

For:
```
/wp-login.php
```
the flow becomes:
```
Browser
 ↓
HTTPS
 ↓
Nginx
 ↓
location ~ \.php$
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
/storage/websites/.../wp-login.php
 ↓
WordPress
```
30. What Happens With CSS?

Request:
```
/wp-content/themes/.../style.css
```
Nginx can usually serve it directly:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
style.css
```
PHP-FPM isn’t needed.

31. What Happens With wp-login.php?

Request:
```
/wp-login.php
```
typically:
```
Browser
 ↓
Nginx
 ↓
PHP location
 ↓
PHP-FPM
 ↓
wp-login.php
 ↓
WordPress
```
32. What Happens With /about/?

Usually:
```
Browser
 ↓
Nginx
 ↓
location /
 ↓
try_files
 ↓
not a physical file
 ↓
/index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
route /about/
```
33. The Nginx Decision Tree

Think of Nginx approximately like:
```
Request arrives
      │
      ▼
Which server_name?
      │
      ▼
Which location?
      │
      ├── Static resource?
      │       ↓
      │    Filesystem
      │
      └── PHP?
              ↓
           FastCGI
              ↓
          PHP-FPM
```
The actual Nginx location-selection algorithm is more nuanced than this simplified tree.

34. TLS Comes Before HTTP Processing

For HTTPS:
```
TCP connection
 ↓
TLS handshake
 ↓
Encrypted HTTP
 ↓
Nginx HTTP processing
```
So the layers are:
```
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx routing
```
35. SNI and server_name

This is a particularly useful connection.

During TLS:
```
SNI:
templates.cresignsys.com
```
Then HTTP contains:
```
Host: templates.cresignsys.com
```
Nginx uses the available information to select the appropriate virtual server configuration.

36. Multiple Domains

Imagine:
```
IP: 203.0.113.10

             Nginx
               │
      ┌────────┼────────┐
      ▼        ▼        ▼
   site A    site B   site C
```
Each can have:
```
server_name
root
TLS certificate
logs
PHP configuration
```
37. Hosting Platform

This is exactly why your hosting platform can create websites automatically.

Your script can generate:
```
server {
    listen 443 ssl;
    server_name example.com;

    root /storage/websites/example.com/public;

    ...
}
```
Then:
```
nginx -t
```
and:
```
systemctl reload nginx
```
The new website becomes active.

38. Configuration Test

Never blindly reload after editing Nginx.

First:
```
sudo nginx -t
```
You want something equivalent to:
```
syntax is ok
test is successful
```
39. Then Reload

If the configuration test succeeds:
```
sudo systemctl reload nginx
```
This tells Nginx to reload configuration without requiring a full service restart.

40. Check Nginx Status
```
sudo systemctl status nginx
```
Useful for seeing:
```
running
failed
inactive
```
41. Check Configuration

A powerful command:
```
sudo nginx -T
```
This prints the complete effective Nginx configuration after includes are processed.

This is extremely useful when debugging complex hosting systems.

42. Find Website Configuration

You can search:
```
sudo nginx -T | grep -n "templates.cresignsys.com"
```
This helps locate where Nginx sees the domain configuration.

43. Logs

Nginx commonly has:
```
/var/log/nginx/
```
with logs such as:
```
access.log
error.log
```
Your configuration may also use separate per-site logs.

44. Access Log

The access log records requests.

Conceptually:
```
GET /about/ HTTP/2
200
```
It can help answer:

What requests are actually reaching the server?

45. Error Log

The error log helps investigate problems such as:
```
PHP-FPM connection failure
Permission denied
File not found
Configuration errors
Upstream failures
```
46. Example Diagnostic

Suppose the browser says:
```
502 Bad Gateway
```
Check:
```
sudo tail -f /var/log/nginx/error.log
```
Then make the request again.

You might discover:
```
connect() to unix:/run/php/php8.x-fpm.sock failed
```
That immediately points toward PHP-FPM/socket configuration.

47. Another Example

Suppose:
```
403 Forbidden
```
Possible areas:
```
Filesystem permissions
Nginx configuration
Directory access
Security rules
Application behavior
```
The error log helps narrow it down.

48. Filesystem Permissions

Suppose your root is:
```
/storage/websites/templates.cresignsys.com/public
```
Nginx needs sufficient permission to read files.

PHP-FPM also needs appropriate access to execute/read the necessary files.

This creates an important relationship:
```
Nginx
+
PHP-FPM
+
Linux permissions
```
49. Linux Users

Your services may run under accounts such as:
```
www-data
```
This is common on Debian/Ubuntu web servers.

The exact user depends on your configuration.

50. Why Ownership Matters

Suppose:
```
file owner = root
permissions = 600
```
and Nginx/PHP-FPM runs as:
```
www-data
```
The web service may not be able to access the file.

This can cause:
```
403
500
application failures
```
depending on the situation.

51. Nginx and WordPress Architecture

Your WordPress website therefore becomes:
```
                  INTERNET
                     │
                     ▼
                 TCP :443
                     │
                     ▼
                    TLS
                     │
                     ▼
                   NGINX
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
      Static files           PHP-FPM
                                  │
                                  ▼
                              WordPress
                                  │
                                  ▼
                                MySQL
```
52. Nginx Is the Traffic Controller

A useful mental model:

Nginx is the traffic controller at the front door of your website.

It decides:
```
Which domain?
Which port?
Which URL?
Which file?
Which application?
Which upstream?
Which response?
```
53. Reverse Proxy

Nginx can also forward requests to another application.

For example:
```
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}
```
Then:
```
Browser
 ↓
Nginx
 ↓
Node.js :3000
```
The browser doesn’t need to know that the application runs on port 3000.

54. PHP vs Reverse Proxy

PHP commonly uses:
```
FastCGI
```
Other applications might use:
```
HTTP reverse proxy
```
For example:
```
Nginx
 ↓
Node.js
```
or:
```
Nginx
 ↓
Python/Gunicorn
```
55. Nginx Can Host Many Technologies

For example:
```
Nginx
│
├── HTML
├── PHP
├── WordPress
├── Node.js
├── Python
├── Go
├── Java applications
└── Reverse-proxied services
```
Nginx itself isn’t the application.

It is often the front-facing web layer.

56. The Most Important Nginx Concepts

Memorize:
```
server
=
virtual server

listen
=
network port/address

server_name
=
hostname matching

root
=
filesystem root

location
=
URI routing rules

try_files
=
filesystem/application fallback

fastcgi_pass
=
send request to PHP-FPM

proxy_pass
=
reverse proxy to HTTP upstream

access_log
=
request log

error_log
=
error/debug log
```
57. Typical WordPress Configuration

A simplified example:
```
server {
    listen 80;
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
```
This is an educational example; your production configuration should match the PHP version, security requirements, and existing hosting setup.

58. HTTPS Version

A simplified HTTPS server might look conceptually like:
```
server {
    listen 443 ssl;
    server_name templates.cresignsys.com;

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

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

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

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
```
Again, the PHP socket and exact directives must match your actual system.

59. What Happens When You Type the URL?

You type:
```
https://templates.cresignsys.com/about/
```
Step 1

Browser performs DNS resolution.
```
templates.cresignsys.com
        ↓
IP
```
Step 2

TCP connection:
```
Browser → server:443
```
Step 3

TLS handshake.
```
ClientHello
ServerHello
Certificate
Key exchange
Finished
```
Step 4

HTTP request:
```
GET /about/ HTTP/2
Host: templates.cresignsys.com
```
Step 5

Nginx selects:
```
server_name
```
Step 6

Nginx evaluates:
```
location /
```
Step 7

try_files checks the requested resource.

Step 8

WordPress receives the request if no matching static resource exists.

Step 9

PHP-FPM executes the PHP code.

Step 10

WordPress queries MySQL if necessary.

Step 11

HTML comes back.

Step 12

Nginx sends the HTTP response.

Step 13

TLS protects the response.

Step 14

Browser renders the page.

60. One Complete Mental Model
```
URL
 │
 ▼
DNS
 │
 ▼
IP
 │
 ▼
TCP :443
 │
 ▼
TLS
 │
 ▼
HTTP
 │
 ▼
NGINX
 │
 ├── server_name
 │
 ├── location
 │
 ├── root
 │
 └── try_files
       │
       ├── static → filesystem
       │
       └── dynamic → FastCGI
                         │
                         ▼
                      PHP-FPM
                         │
                         ▼
                      WordPress
                         │
                         ▼
                       MySQL
```
This is the architecture you need to understand before building a serious multi-domain hosting platform.

Lesson 042 Summary

The key idea:

Nginx receives the HTTP request and decides what should happen to it.

For a static file:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
Response
```
For WordPress:
```
Browser
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Nginx
 ↓
Browser
```
For HTTPS:
```
Browser
 ↓
TCP :443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
```
Next Lesson — 043

Linux Filesystem + Permissions — The Hidden Foundation of Web Hosting

Before going deeper into PHP-FPM and WordPress, we need to understand why these commands matter:
```
ls -la
chown
chmod
sudo
www-data
root
```
We will go from the absolute basics:
```
File
Directory
Path
Owner
Group
Permission
Read
Write
Execute
```
to the actual hosting structure:
```
/storage/websites/
    │
    ├── domain1.com/
    │      └── public/
    │
    ├── domain2.com/
    │      └── public/
    │
    └── domain3.com/
           └── public/
```
and then understand exactly why Nginx, PHP-FPM, WordPress, Certbot, and SSH need different permissions.
August 13, 2026

Record	Purpose
A	IPv4 address
AAAA	IPv6 address
CNAME	Alias to another hostname
MX	Mail server
TXT	Text/verification/authentication data
NS	Authoritative nameserver
SOA	Zone authority information

ID	post_title	post_type	post_status
10	About Us	page	publish
11	Welcome	post	publish
12	Logo	attachment	inherit

ID	user_login	user_email
1	admin	admin@example.com
2	john	john@example.com

post_id	meta_key	meta_value
10	page_template	default
10	custom_color	blue

Author: cresignsys

CresignSys Learn — Lesson 051

Linux Processes — From Program to Running Service

1. Program vs Process

Program

Process

2. Simple Example

3. Running Program

4. PID

PID

5. Find Processes

6. top

7. htop

8. Process Hierarchy

9. PID 1

systemd

10. Why PID 1 Matters

11. systemd Starts Services

12. systemctl

13. Service vs Process

14. Installed

15. Enabled

enabled

16. Started

17. Restart

18. Reload

19. Restart vs Reload

Restart

Reload

20. Nginx Example

21. Why nginx -t?

22. Very Important Workflow

23. Process Command

24. Find Nginx PID

25. Process Tree

26. Why Process Trees Matter

27. Nginx Master and Worker Processes

28. Why Multiple Workers?

29. PHP-FPM

30. WordPress Request

31. PHP-FPM Worker

32. MySQL Process

33. SSH Process

34. Cron

35. Certbot / ACME

36. Process Memory

37. Why PHP-FPM Can Consume Lots of RAM

38. Too Many Workers

39. Process CPU

40. CPU Percentage Can Be Misunderstood

41. Load Average

Load Average

42. What Does Load Mean?

43. Example

44. High Load ≠ Automatically Bad

45. CPU Count

46. Process States

47. Zombie Process

48. Why Zombies Exist

Reaping

49. Don’t Panic About One Zombie

50. Killing a Process

51. SIGTERM

52. SIGKILL

53. Why kill -9 Is Not the First Choice

54. Service Restart Is Usually Better

55. Parent Process

Parent Process ID

56. View Parent Process

57. Why Parent/Child Matters

58. Process Lifecycle

59. File Descriptors

File Descriptors

60. Why This Matters

61. File Descriptor Limits

62. Nginx and Many Connections

63. Process Scheduling

64. CPU Time

65. Nice Value

Nice

6. `top`

7. `htop`

12. `systemctl`

21. Why `nginx -t`?

53. Why `kill -9` Is Not the First Choice

69. `failed`