MySQL for Web Hosting — Databases, Users, Privileges & WordPress

We now move to the database layer.

Your WordPress request currently travels like this:

Browser
 ↓
DNS
 ↓
IP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

The purpose of MySQL is to store and retrieve the structured data WordPress needs.

---

1. What Is MySQL?

MySQL is a relational database management system.

It stores information in structured tables.

For WordPress, that includes things such as:

posts
pages
users
settings
comments
categories
menus
plugin data
theme data
metadata

---

2. WordPress Is Not the Database

This distinction is important.

WordPress
=
application

MySQL
=
database

The relationship is:

WordPress
   ↓
SQL queries
   ↓
MySQL
   ↓
data

---

3. What Is a Database?

A database is a logical collection of related data.

For example:

wordpress_learn

might contain tables such as:

wp_posts
wp_users
wp_options
wp_terms
wp_comments

---

4. Database Server vs Database

These are different.

MySQL server

The running database service.

Database

A logical collection inside that server.

Conceptually:

MySQL Server
│
├── database1
├── database2
├── database3
└── database4

---

5. Your Hosting Server

You may have:

Ubuntu VPS
│
├── Nginx
├── PHP-FPM
├── MySQL
├── WordPress site 1
├── WordPress site 2
└── WordPress site 3

All websites can use the same MySQL server while having separate databases.

---

6. One Database Per Website

For hosting, a good model is:

site1.com
 ↓
database_site1

site2.com
 ↓
database_site2

site3.com
 ↓
database_site3

This makes management and isolation easier.

---

7. Why Not One Database for Everything?

You could technically put many websites into one database.

But it creates problems:

harder backup
harder restore
harder migration
harder isolation
harder troubleshooting

Therefore, for your hosting platform:

One website → one database is a useful standard.

---

8. Database User

A database should also have a dedicated database user.

For example:

Website:
learn.cresignsys.com

Database:
learn_cresignsys

User:
learn_user

The application uses that user to access its database.

---

9. Why Dedicated Users?

Suppose:

site1
site2

both use the same MySQL account.

If site1 is compromised, the attacker may potentially gain access to site2’s database as well.

Instead:

site1 → db_user1 → database1

site2 → db_user2 → database2

provides better isolation.

---

10. MySQL Architecture

Conceptually:

WordPress
    │
    │ SQL
    ▼
MySQL Server
    │
    ├── Database 1
    │
    ├── Database 2
    │
    └── Database 3

---

11. Check MySQL

On Ubuntu:

sudo systemctl status mysql

You want:

Active: active (running)

---

12. Check MySQL Version

Run:

mysql --version

You may see something similar to:

mysql  Ver 8.0...

The exact version depends on your installation.

---

13. Enter MySQL

On a server using local administrative authentication, you may use:

sudo mysql

You should then see:

mysql>

---

14. Exit

To leave MySQL:

EXIT;

or:

\q

---

15. List Databases

Inside MySQL:

SHOW DATABASES;

You may see:

information_schema
mysql
performance_schema
sys

plus your WordPress databases.

---

16. System Databases

MySQL includes databases used internally.

For example:

mysql
information_schema
performance_schema
sys

Don’t delete these casually.

---

17. Create a Database

Example:

CREATE DATABASE learn_cresignsys;

Now:

learn_cresignsys

exists.

---

18. Better Character Set

For WordPress, Unicode support is important.

A commonly used configuration is:

CREATE DATABASE learn_cresignsys
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

The exact collation choice can vary by MySQL version and application requirements.

---

19. Why utf8mb4?

It supports a much broader range of Unicode characters than the older MySQL utf8 implementation.

For example:

English
Malayalam
Hindi
Arabic
Chinese
emoji

can all be represented properly when the application and database configuration are compatible.

---

20. Database User

Create a dedicated user:

CREATE USER 'learn_user'@'localhost'
IDENTIFIED BY 'STRONG_PASSWORD';

Use a strong, unique password.

Do not reuse your Linux password.

---

21. Grant Privileges

Give the user access to its own database:

GRANT ALL PRIVILEGES
ON learn_cresignsys.*
TO 'learn_user'@'localhost';

Now:

learn_user

can operate on:

learn_cresignsys

---

22. What Does *.* Mean?

This is important.

database.*

means:

All tables in this database.

For example:

learn_cresignsys.*

means:

all tables inside learn_cresignsys

---

23. Why Not Give Global Privileges?

Avoid doing this for normal WordPress users:

GRANT ALL PRIVILEGES ON *.* ...

That could give access to every database.

Instead:

learn_user
 ↓
learn_cresignsys.*

This follows least privilege.

---

24. Least Privilege

A core security principle:

Give an application only the permissions it needs.

For example:

Site 1
 ↓
Database 1

not:

Site 1
 ↓
Every database

---

25. WordPress Database Credentials

WordPress stores database connection information in:

wp-config.php

Typically:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

---

26. Example

Conceptually:

define( 'DB_NAME', 'learn_cresignsys' );
define( 'DB_USER', 'learn_user' );
define( 'DB_PASSWORD', 'STRONG_PASSWORD' );
define( 'DB_HOST', 'localhost' );

Do not publish real credentials.

---

27. What Happens During a Request?

Suppose:

https://learn.cresignsys.com/about/

is requested.

The flow is:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
wp-config.php
 ↓
MySQL

WordPress reads the database connection settings and connects to MySQL.

---

28. MySQL Query

WordPress may execute queries conceptually similar to:

SELECT *
FROM wp_posts
WHERE ID = 123;

MySQL processes the query.

Then returns the result to PHP.

---

29. PHP Receives Data

The flow becomes:

MySQL
 ↓
database result
 ↓
WordPress/PHP
 ↓
HTML
 ↓
Nginx
 ↓
Browser

---

30. Tables

A relational database stores data in tables.

For example:

wp_users

may contain:

ID
user_login
user_email
user_pass

and other fields.

---

31. Rows

A row represents one record.

For example:

ID = 15
user_login = john

is one user record.

---

32. Columns

Columns describe the fields.

Example:

wp_users

ID
user_login
user_email
user_registered

---

33. Primary Key

A table normally has a way to uniquely identify each record.

For example:

ID

can act as a primary key.

Conceptually:

ID
--
1
2
3
4

Each identifies a particular record.

---

34. WordPress Tables

A standard WordPress installation commonly creates tables such as:

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.

---

35. Table Prefix

Notice:

wp_

is a common table prefix.

WordPress can use another prefix.

For example:

abc_posts
abc_users
abc_options

---

36. Why Prefix Exists

The prefix can help distinguish WordPress tables.

It can also allow multiple WordPress installations to use the same database in some configurations, although separate databases are generally cleaner for independent hosted sites.

---

37. Never Treat Prefix as Complete Security

Changing:

wp_

to:

abc_

does not provide meaningful protection by itself.

Real security comes from:

database privileges
Linux permissions
application security
updates
authentication
network controls

---

38. Check WordPress Tables

Inside MySQL:

USE learn_cresignsys;

Then:

SHOW TABLES;

You should see the WordPress tables.

---

39. Inspect a Table

For example:

DESCRIBE wp_options;

This shows the columns.

---

40. Count Posts

You could query:

SELECT COUNT(*)
FROM wp_posts;

This is a simple example of how WordPress data is stored.

---

41. Don’t Modify WordPress Directly Without Understanding It

You can technically run:

UPDATE ...

but be careful.

WordPress plugins and themes can have relationships and serialized/structured data.

Changing database records manually can break the application.

For normal content management:

WordPress Admin

is usually safer.

---

42. MySQL User Authentication

MySQL identifies users by:

username
+
host

For example:

'learn_user'@'localhost'

is different from:

'learn_user'@'%'

---

43. localhost

For:

'learn_user'@'localhost'

the account is intended for connections from the local host under MySQL’s account matching rules.

This is appropriate when:

WordPress
+
MySQL

are on the same VPS.

---

44. Why Avoid %?

You may see:

'learn_user'@'%'

which broadly permits connections from hosts matching %.

For a local-only WordPress database connection, you generally don’t need to expose the database user this broadly.

Prefer the narrowest host requirement that works.

---

45. Database Port

MySQL commonly listens on:

3306

But don’t assume the port alone makes MySQL accessible.

Check:

sudo ss -ltnp | grep 3306

---

46. MySQL Should Usually Not Be Public

For your single VPS:

Internet
   ✕
   ↓
MySQL 3306

You generally don’t want arbitrary Internet users connecting directly to your WordPress MySQL service.

Instead:

Internet
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL

MySQL remains internal to the server.

---

47. Check MySQL Bind Address

Inspect MySQL configuration.

For example:

sudo grep -R "bind-address" /etc/mysql/ 2>/dev/null

You may find something such as:

127.0.0.1

This means MySQL is bound to the local interface.

The exact configuration depends on your installation.

---

48. Why This Is Secure

If MySQL listens only locally:

Internet
  ↓
Nginx
  ↓
PHP
  ↓
localhost
  ↓
MySQL

external systems cannot directly reach the MySQL service through the network.

---

49. If You Need Remote MySQL

There are legitimate cases where:

Application Server
        ↓
network
        ↓
Database Server

is required.

Then you need:

TLS
firewall rules
restricted source IPs
database privileges
authentication

Don’t simply open:

3306

to the whole Internet.

---

50. WordPress Database Architecture

Your current hosting architecture should be:

                    INTERNET
                        │
                        ▼
                      NGINX
                        │
                        ▼
                    PHP-FPM
                        │
                        ▼
                    WORDPRESS
                        │
                        ▼
                     MYSQL
                        │
              ┌─────────┼─────────┐
              ▼         ▼         ▼
             DB1       DB2       DB3

---

51. One Website

For:

learn.cresignsys.com

use:

Linux user:
learn

Website:
learn.cresignsys.com

Database:
learn_cresignsys

Database user:
learn_user

PHP-FPM pool:
learn

PHP socket:
learn.sock

Conceptually:

learn.cresignsys.com
        │
        ├── files
        ├── Nginx
        ├── PHP-FPM
        └── MySQL
             │
             └── learn_cresignsys

---

52. Another Website

For:

shop.cresignsys.com

use:

shop
shop_cresignsys
shop_user
shop PHP-FPM pool
shop.sock

Now the two sites are logically separated.

---

53. Database Backup

Database backup is essential.

A common tool is:

mysqldump

For example:

mysqldump -u learn_user -p learn_cresignsys > learn_cresignsys.sql

This exports database contents to a SQL file.

---

54. What Is a SQL Dump?

A dump can contain SQL statements that recreate database objects and data.

Conceptually:

Database
   ↓
mysqldump
   ↓
backup.sql

Later:

backup.sql
   ↓
mysql
   ↓
Database

---

55. Restore Example

Create the target database first, then import:

mysql -u learn_user -p learn_cresignsys < learn_cresignsys.sql

The exact restore procedure depends on what is contained in the dump and how the target database/user is configured.

---

56. Database Backup Is Not Website Backup

This is critical.

A WordPress backup needs at least:

Database
+
Website files

because:

database

contains content/settings, while:

wp-content
themes
plugins
uploads
WordPress files

are stored on disk.

---

57. Full WordPress Backup

Conceptually:

WordPress Backup
│
├── Database
│    └── .sql
│
└── Files
     └── website directory

---

58. Why wp-content Is Important

Among WordPress files:

wp-content/

usually contains important site-specific data such as:

plugins
themes
uploads

The uploads directory is particularly important because it contains media files.

---

59. Backup Strategy for Hosting

For each hosted website:

site1
├── database backup
└── files backup

site2
├── database backup
└── files backup

site3
├── database backup
└── files backup

---

60. Database Size

Check database size:

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 = 'learn_cresignsys'
GROUP BY table_schema;

This helps monitor growth.

---

61. Why Database Size Matters

A WordPress database can grow due to:

posts
revisions
logs
plugin tables
transients
analytics
comments
metadata

Poorly configured plugins can create very large tables.

---

62. MySQL Performance

MySQL consumes:

RAM
CPU
disk I/O

WordPress performance therefore depends on:

Nginx
+
PHP-FPM
+
MySQL
+
storage

not only PHP.

---

63. Request Flow With Database

A dynamic request may look like:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
data
 ↓
WordPress
 ↓
PHP
 ↓
Nginx
 ↓
Browser

Every layer can become a bottleneck.

---

64. Database Bottleneck

Suppose PHP is fast but MySQL takes:

5 seconds

Then the page can still take roughly:

5+ seconds

before other processing and network overhead.

Therefore:

Faster PHP cannot completely compensate for a slow database.

---

65. Query

A database query asks MySQL to retrieve or modify information.

For example:

SELECT *
FROM wp_posts
WHERE post_status = 'publish';

The database parses and executes it.

---

66. Index

Indexes help MySQL find records efficiently.

Conceptually:

Without index
 ↓
scan many rows

With appropriate index
 ↓
find relevant rows faster

WordPress core tables have indexes designed for common operations, and plugins may add their own.

---

67. Too Many Queries

A page can trigger many database queries.

For example:

WordPress
 ↓
100 queries
 ↓
MySQL

If each query is expensive, page generation becomes slow.

Caching can reduce the need to regenerate the page.

---

68. Object Cache

WordPress can also use object caching.

Conceptually:

WordPress
 ↓
Object cache
 ↓
data

instead of querying MySQL repeatedly for the same information.

Common technologies include Redis and Memcached, but these are later lessons.

---

69. Database Security Model

Your hosting platform should follow:

Website
 ↓
Dedicated database user
 ↓
Dedicated database
 ↓
Minimum required privileges

Not:

Website
 ↓
root MySQL account
 ↓
all databases

---

70. Never Use MySQL Root in WordPress

Do not configure:

define( 'DB_USER', 'root' );

for a normal WordPress site.

Instead:

site-specific database user

should be used.

---

71. Why Root Is Dangerous

If WordPress is compromised and it has MySQL root privileges, the attacker could potentially perform actions far beyond that site’s database.

Least privilege limits the potential impact.

---

72. Your Hosting Creation Workflow

A proper automated site creation process should eventually do:

DOMAIN
  ↓
Linux user
  ↓
Website directory
  ↓
PHP-FPM pool
  ↓
Nginx server block
  ↓
Database
  ↓
Database user
  ↓
Privileges
  ↓
WordPress
  ↓
SSL

---

73. Example: learn.cresignsys.com

Conceptual configuration:

DOMAIN
learn.cresignsys.com

LINUX USER
learn

PATH
/storage/websites/learn.cresignsys.com/public

DATABASE
learn_cresignsys

DATABASE USER
learn_user

PHP POOL
learn

SOCKET
/run/php/learn.sock

Then:

DNS
 ↓
Nginx
 ↓
learn PHP-FPM
 ↓
learn WordPress
 ↓
learn database

---

74. This Is Multi-Tenant Hosting

When multiple independent websites share one server, you are operating a form of:

Multi-tenant hosting

Example:

Server
│
├── Customer A
├── Customer B
├── Customer C
└── Customer D

Each tenant needs isolation.

---

75. Isolation Layers

You can isolate at several levels:

Linux user
+
filesystem permissions
+
PHP-FPM pool
+
database
+
database user
+
Nginx configuration

The more layers are correctly separated, the stronger the hosting architecture.

---

76. Important Distinction

Separate:

database

does not automatically mean:

full security isolation

You also need:

filesystem isolation
process isolation
correct PHP-FPM users
correct permissions
secure Nginx configuration

---

77. MySQL Commands to Memorize

Check databases:

SHOW DATABASES;

Select database:

USE database_name;

List tables:

SHOW TABLES;

Describe table:

DESCRIBE table_name;

Create database:

CREATE DATABASE database_name;

Create user:

CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';

Grant access:

GRANT ALL PRIVILEGES
ON database_name.*
TO 'user'@'localhost';

---

78. Linux Commands to Memorize

Check MySQL:

sudo systemctl status mysql

Enter MySQL:

sudo mysql

Check listening port:

sudo ss -ltnp | grep 3306

Check version:

mysql --version

Backup:

mysqldump -u USER -p DATABASE > backup.sql

Restore:

mysql -u USER -p DATABASE < backup.sql

---

79. Complete Architecture

You now understand:

                     INTERNET
                        │
                        ▼
                       DNS
                        │
                        ▼
                    PUBLIC IP
                        │
                        ▼
                 OCI NETWORKING
                        │
                        ▼
                      NGINX
                        │
                        ▼
                    PHP-FPM
                        │
                        ▼
                   WORDPRESS
                        │
                        ▼
                      MYSQL

And for multiple websites:

                      NGINX
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       Site 1        Site 2        Site 3
          │             │             │
       PHP 1          PHP 2          PHP 3
          │             │             │
        DB 1           DB 2           DB 3

---

80. Lesson 061 — Core Principle

The most important principle is:

Each hosted website should have its own application identity and database identity whenever practical.

For your CresignSys hosting architecture:

Domain
 ↓
Linux User
 ↓
Website Files
 ↓
Nginx Server Block
 ↓
PHP-FPM Pool
 ↓
PHP Socket
 ↓
WordPress
 ↓
Dedicated Database
 ↓
Dedicated Database User

This gives you a clean foundation for automated multi-domain hosting.

---

Next Lesson — 062

Linux Users, Groups & Permissions for Multi-Website Hosting

Next we will connect MySQL security with the filesystem and PHP-FPM security:

Linux User
 ↓
Group
 ↓
UID
 ↓
GID
 ↓
file ownership
 ↓
r / w / x
 ↓
chmod
 ↓
chown
 ↓
umask
 ↓
setgid
 ↓
ACL

Then we will design the correct permissions for:

/storage/websites/
├── site1.com/
├── site2.com/
└── site3.com/

so that Site 1 cannot modify Site 2, even though both run on the same VPS.

PHP-FPM Deep Dive — How Nginx Runs WordPress PHP

We now move from Nginx to the PHP execution layer.

The complete flow is:

Browser
   ↓
DNS
   ↓
IP
   ↓
TCP 443
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL

The key concept:

Nginx does not execute PHP. PHP-FPM executes PHP for Nginx.

---

1. What Is PHP?

PHP is a server-side programming language.

WordPress is primarily written in PHP.

For example:

index.php
wp-load.php
wp-settings.php

are PHP files.

The browser does not normally receive the PHP source code.

Instead:

PHP source
   ↓
PHP execution
   ↓
HTML
   ↓
Browser

---

2. Why PHP-FPM Exists

Nginx is excellent at:

HTTP
HTTPS
static files
connections
proxying

But it doesn’t execute PHP.

Therefore:

Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
PHP

---

3. PHP-FPM

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

Conceptually:

PHP-FPM
│
├── Worker 1
├── Worker 2
├── Worker 3
└── Worker 4

Each worker can execute PHP requests.

---

4. Check PHP-FPM

On Ubuntu, first check which PHP version is installed:

php -v

Then:

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

You may see something similar to:

php8.3-fpm.service

The exact version on your server may be different.

---

5. Check the Service

For example:

sudo systemctl status php8.3-fpm

If your installed version differs, substitute it.

You want:

Active: active (running)

---

6. PHP CLI vs PHP-FPM

These are different.

PHP CLI

php

runs PHP from the command line.

PHP-FPM

php-fpm

runs PHP workers that applications such as Nginx can communicate with.

So:

CLI
=
command-line PHP

while:

FPM
=
web-request PHP execution

---

7. PHP-FPM Master Process

PHP-FPM generally has a master process.

Conceptually:

PHP-FPM
   │
   └── Master
         │
         ├── Worker
         ├── Worker
         ├── Worker
         └── Worker

The master manages the worker pool.

---

8. Worker Processes

When PHP requests arrive:

Nginx
 ↓
PHP-FPM
 ↓
available worker
 ↓
execute PHP

The worker processes the PHP request.

---

9. Why Multiple Workers?

Suppose:

User A → WordPress
User B → WordPress
User C → WordPress
User D → WordPress

You don’t want one PHP process to handle everything serially.

Multiple workers allow concurrent processing.

Conceptually:

Request A → Worker 1
Request B → Worker 2
Request C → Worker 3
Request D → Worker 4

---

10. PHP-FPM Pool

A group of PHP workers is called a:

Pool

A PHP-FPM installation can have multiple pools.

For example:

PHP-FPM
│
├── www pool
├── site1 pool
├── site2 pool
└── site3 pool

---

11. Why Pools Matter for Hosting

If you have:

site1.com
site2.com
site3.com

you could use one shared pool:

All websites
      ↓
www pool

or separate pools:

site1 → site1 pool
site2 → site2 pool
site3 → site3 pool

For a hosting platform, separate pools can provide stronger isolation and more controllable resource limits.

---

12. Shared Pool

Simple architecture:

Nginx
   │
   ▼
PHP-FPM
   │
   ▼
www pool
   │
   ├── site1
   ├── site2
   └── site3

Advantages:

simple
fewer processes
easy management

Disadvantages:

weaker isolation
one busy site can consume shared PHP capacity

---

13. Separate Pools

More isolated:

Nginx
│
├── site1 → PHP pool 1
├── site2 → PHP pool 2
└── site3 → PHP pool 3

Advantages:

better isolation
different users
different limits
different PHP settings

Disadvantages:

more configuration
more process-management complexity
more memory overhead

---

14. Hosting Architecture

For your CresignSys hosting platform, the long-term architecture can be:

site1
 ├── Linux user
 ├── files
 ├── Nginx config
 ├── PHP-FPM pool
 ├── PHP socket
 └── database

site2
 ├── Linux user
 ├── files
 ├── Nginx config
 ├── PHP-FPM pool
 ├── PHP socket
 └── database

---

15. Unix Socket

Nginx and PHP-FPM can communicate using a Unix socket.

Example:

/run/php/site1.sock

Flow:

Nginx
 ↓
Unix socket
 ↓
PHP-FPM

---

16. Why Unix Socket?

When both services are on the same server, a Unix socket is often a simple and efficient local communication mechanism.

You don’t need a network IP/port between Nginx and PHP-FPM.

---

17. TCP Socket

PHP-FPM can also listen on TCP.

For example:

127.0.0.1:9000

Then:

Nginx
 ↓
127.0.0.1:9000
 ↓
PHP-FPM

---

18. Unix vs TCP

For your single-server hosting setup:

Unix socket

is often convenient.

For distributed architectures:

TCP

can be more appropriate.

For example:

Nginx Server
     ↓
network
     ↓
PHP Application Server

requires network communication.

---

19. PHP-FPM Configuration

Configuration locations vary by PHP version.

A common structure is:

/etc/php/<version>/fpm/

with:

php-fpm.conf
pool.d/

Inside:

pool.d/

you may find:

www.conf

---

20. Default Pool

A common default pool is:

www

with configuration such as:

/etc/php/8.x/fpm/pool.d/www.conf

The exact path depends on your installed PHP version.

---

21. Pool Configuration

A simplified pool configuration might look like:

[site1]

user = site1
group = site1

listen = /run/php/site1.sock

Then process-management settings can be added.

---

22. User and Group

This is extremely important for hosting.

Suppose:

site1

has its own Linux user.

PHP-FPM workers for that pool can run as:

site1

instead of:

www-data

This improves isolation between websites.

---

23. Why User Isolation Matters

Suppose:

site1
site2

are owned by different customers.

If both PHP applications run as:

www-data

then filesystem separation can become more difficult.

With:

site1 → user1
site2 → user2

you can enforce stronger boundaries.

---

24. Example

/storage/websites/
│
├── site1.com/
│   └── public/
│
└── site2.com/
    └── public/

Ownership:

site1.com → site1
site2.com → site2

PHP:

site1 pool → site1
site2 pool → site2

This creates a consistent security model.

---

25. Nginx Worker User

Nginx may still run workers as:

www-data

while PHP runs as:

site1

This is possible if the relevant filesystem and socket permissions are configured correctly.

---

26. Socket Permission Problem

Suppose PHP-FPM creates:

/run/php/site1.sock

owned by:

site1:site1

If Nginx cannot access it:

Nginx
 ↓
socket permission denied
 ↓
502 Bad Gateway

This is one of the most important causes of PHP-related 502 errors.

---

27. Socket Ownership

Pool configuration can specify socket ownership and permissions.

Conceptually:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

This is only an example; the correct ownership model depends on how you isolate Nginx and PHP-FPM.

---

28. Process Manager

PHP-FPM has process management settings.

The most important modes are:

static
dynamic
ondemand

---

29. static

With:

pm = static

PHP-FPM maintains a fixed number of worker processes.

For example:

pm.max_children = 5

means approximately five worker processes are maintained.

---

30. dynamic

With:

pm = dynamic

PHP-FPM adjusts the number of workers within configured limits.

Important settings include:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

---

31. ondemand

With:

pm = ondemand

workers are created when requests arrive and can be terminated after being idle.

This can be useful for sites with relatively low or irregular traffic.

---

32. pm.max_children

This is one of the most important settings.

Example:

pm.max_children = 10

It limits the maximum number of simultaneous PHP worker processes in that pool.

---

33. Why This Matters

Suppose one PHP request consumes:

100 MB RAM

and you allow:

10 workers

Very roughly:

10 × 100 MB
=
1000 MB

plus:

Nginx
MySQL
OS
cache
other processes

So PHP worker limits must be based on actual memory usage, not arbitrary large numbers.

---

34. Too Few Workers

Suppose:

pm.max_children = 2

but:

20 requests

arrive simultaneously.

Only two PHP requests can execute at once.

The others wait.

This can increase response time.

---

35. Too Many Workers

Suppose:

pm.max_children = 100

but your VPS has limited RAM.

If PHP workers consume significant memory:

100 workers
 ↓
RAM exhaustion
 ↓
swap/OOM
 ↓
slow server
 ↓
possible crashes

Therefore:

More PHP workers does not automatically mean more performance.

---

36. CPU Also Matters

PHP workers consume:

RAM
CPU

Some requests are CPU-intensive.

For example:

large WordPress plugin
image processing
complex database operations

can consume significant resources.

---

37. Worker Concurrency

Think:

pm.max_children
=
maximum PHP concurrency for that pool

It is not simply:

number of visitors

One visitor can generate multiple requests.

And not every request requires PHP.

---

38. Static Files Don’t Need PHP

For:

logo.png
style.css
script.js

Nginx can often serve them directly.

Therefore:

100 static requests

do not necessarily mean:

100 PHP workers

---

39. WordPress Dynamic Requests

Requests such as:

/wp-admin/
login
uncached pages
POST requests
AJAX/API operations

may require PHP.

The exact behavior depends on the application and caching configuration.

---

40. PHP-FPM Queue

If all workers are busy:

Request
 ↓
PHP-FPM
 ↓
no free worker
 ↓
wait

Too much waiting can produce slow responses and eventually upstream timeouts.

---

41. pm.max_requests

Another useful setting:

pm.max_requests = 500

This tells a worker to process a limited number of requests before being recycled.

Why?

Long-running PHP processes can sometimes accumulate memory or other state.

Recycling workers can help mitigate certain forms of gradual memory growth.

---

42. pm.start_servers

For dynamic mode:

pm.start_servers = 3

controls how many workers are started initially.

---

43. pm.min_spare_servers

Example:

pm.min_spare_servers = 2

controls the minimum number of idle workers maintained in dynamic mode.

---

44. pm.max_spare_servers

Example:

pm.max_spare_servers = 5

controls the maximum number of idle workers maintained.

---

45. Example Pool

A simplified educational example:

[site1]

user = site1
group = site1

listen = /run/php/site1.sock

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

These numbers are examples, not recommended defaults for your VPS.

---

46. Resource Calculation

Before choosing:

pm.max_children

measure actual PHP worker memory usage.

For example:

ps --no-headers -o rss,cmd -C php-fpm8.3

The exact process name depends on your PHP version.

---

47. RSS

RSS means:

Resident Set Size

It provides an approximation of how much physical memory a process currently occupies.

For PHP-FPM tuning, this is useful.

---

48. Better Principle

Don’t say:

My VPS has 8 GB RAM, so I’ll set 50 PHP workers.

Instead:

Available RAM
 ↓
reserve RAM for OS
 ↓
reserve RAM for MySQL
 ↓
reserve RAM for Nginx
 ↓
reserve RAM for other services
 ↓
remaining RAM
 ↓
measure PHP worker size
 ↓
calculate reasonable concurrency

---

49. Example Calculation

Suppose:

VPS RAM = 8 GB

Reserve approximately:

OS + services = 2 GB
MySQL = 2 GB

Remaining:

4 GB

If average PHP worker usage is:

100 MB

then a theoretical upper bound is roughly:

4000 / 100
=
40 workers

But you should not automatically configure 40.

You need safety margin and real workload measurements.

---

50. WordPress Can Vary Greatly

One PHP request might use:

50 MB

while another might use:

250 MB

depending on:

plugins
theme
queries
image processing
API calls
application state

Therefore average and peak behavior matter.

---

51. PHP-FPM Slow Requests

PHP-FPM can be configured with a:

Slowlog

This helps identify requests that take too long.

A slowlog can help you discover:

slow plugin
slow WordPress operation
slow PHP script
database-related delay

---

52. Request Timeout

Nginx also has upstream timeout settings.

Conceptually:

Nginx
 ↓
waiting for PHP-FPM
 ↓
too long
 ↓
timeout

This can produce:

504 Gateway Timeout

---

53. 502 vs 504

Remember:

502

Often:

Nginx
 ↓
can't properly communicate with upstream

504

Often:

Nginx
 ↓
upstream didn't respond in time

These are clues, not absolute diagnoses.

---

54. Check PHP-FPM Logs

Depending on your installation:

sudo journalctl -u php8.3-fpm

or:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"

Replace the version with your installed PHP-FPM service.

---

55. Check Nginx Errors

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

Then load the website.

Watch what appears.

This is an excellent troubleshooting technique.

---

56. Real-Time Debugging

Open terminal 1:

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

Open terminal 2:

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

Now observe whether Nginx reports an error.

---

57. PHP-FPM Status

You can also inspect:

systemctl status php8.3-fpm

Then:

ps aux | grep php-fpm

You may see:

master process
pool site1
pool site2

---

58. One Pool Per Website

Your future CresignSys architecture could look like:

PHP-FPM
│
├── site1.com
│    ├── user = site1
│    └── socket = site1.sock
│
├── site2.com
│    ├── user = site2
│    └── socket = site2.sock
│
└── site3.com
     ├── user = site3
     └── socket = site3.sock

---

59. Nginx Mapping

Then:

site1.com
 ↓
Nginx server block
 ↓
site1.sock
 ↓
site1 PHP-FPM pool

and:

site2.com
 ↓
Nginx server block
 ↓
site2.sock
 ↓
site2 PHP-FPM pool

---

60. Stronger Isolation

Now imagine:

site1

is compromised through a vulnerable plugin.

If its PHP processes run as:

site1

rather than a shared hosting user, access to other sites can be more strongly restricted by filesystem permissions.

This is one reason shared-hosting systems isolate accounts.

---

61. Important Security Rule

Do not assume:

different directories
=
security isolation

If all applications run under the same powerful user:

www-data

one compromised application may potentially access other files that user can read.

User/process isolation is therefore important in multi-tenant hosting.

---

62. Database Isolation Too

The same principle applies to MySQL.

Instead of:

all websites
 ↓
one database
 ↓
one powerful database user

prefer:

site1
 ↓
database1
 ↓
dbuser1

site2
 ↓
database2
 ↓
dbuser2

with only the required privileges.

---

63. Complete Per-Site Isolation Model

A strong hosting model looks like:

SITE 1
│
├── Linux user
├── filesystem
├── Nginx server block
├── PHP-FPM pool
├── PHP socket
├── database
└── database user


SITE 2
│
├── Linux user
├── filesystem
├── Nginx server block
├── PHP-FPM pool
├── PHP socket
├── database
└── database user

---

64. Your Hosting Automation

When you create a new domain:

create-site example.com

your automation can eventually perform:

1. Create Linux user
2. Create website directories
3. Set ownership
4. Create PHP-FPM pool
5. Create PHP socket
6. Create Nginx configuration
7. Validate Nginx
8. Reload Nginx
9. Create MySQL database
10. Create database user
11. Install WordPress
12. Configure SSL

---

65. The Most Important PHP-FPM Settings

At your current level, memorize:

user
group
listen
pm
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests

---

66. Their Meaning

user
→ Which Linux user executes PHP?

group
→ Which Linux group?

listen
→ Where does Nginx connect?

pm
→ How are PHP workers managed?

pm.max_children
→ Maximum simultaneous PHP workers

pm.start_servers
→ Initial workers

pm.min_spare_servers
→ Minimum idle workers

pm.max_spare_servers
→ Maximum idle workers

pm.max_requests
→ Requests before recycling a worker

---

67. The Complete PHP Request

Now combine everything:

Browser
   ↓
HTTPS
   ↓
Nginx
   ↓
location /
   ↓
try_files
   ↓
index.php
   ↓
FastCGI
   ↓
PHP-FPM socket
   ↓
PHP-FPM pool
   ↓
PHP worker
   ↓
WordPress
   ↓
MySQL

---

68. Where 502 Happens

Nginx
   ↓
PHP-FPM

If this communication fails:

502 Bad Gateway

Investigate:

PHP-FPM running?
 ↓
socket exists?
 ↓
socket permissions?
 ↓
correct socket path?
 ↓
correct PHP-FPM pool?

---

69. Where 504 Happens

Usually:

Nginx
   ↓
PHP-FPM
   ↓
long-running request

If the upstream takes too long:

504 Gateway Timeout

Investigate:

slow PHP
slow WordPress
slow plugin
slow MySQL
external API
resource exhaustion

---

70. Lesson 060 — Core Principle

Remember this:

Nginx receives the web request; PHP-FPM provides the PHP execution environment.

The architecture is:

                  INTERNET
                     │
                     ▼
                   NGINX
                     │
               FastCGI │
                     ▼
                 PHP-FPM
                     │
              ┌──────┴──────┐
              ▼             ▼
           Site 1        Site 2
           Pool 1        Pool 2
              │             │
              ▼             ▼
          WordPress      WordPress
              │             │
              ▼             ▼
           MySQL 1        MySQL 2

This is the foundation for turning your Ubuntu VPS into a proper multi-website hosting server.

---

Next Lesson — 061

MySQL for Hosting — Databases, Users, Privileges & WordPress

We will next learn:

MySQL
 ↓
Database
 ↓
Table
 ↓
Row
 ↓
Column
 ↓
Database user
 ↓
Privileges
 ↓
WordPress wp-config.php
 ↓
PHP → MySQL

Then we will design the correct one-database + one-database-user-per-website model for your CresignSys hosting platform and learn how to create it safely from the command line.

Nginx Deep Dive — How One Server Hosts Many Websites

We now reach the web-server layer.

You already understand:

Domain
 ↓
DNS
 ↓
IP
 ↓
Network
 ↓
TCP 443
 ↓
TLS
 ↓
HTTP

Now we need to understand what happens when that request reaches Nginx.

---

1. What Is Nginx?

Nginx is a high-performance web server and reverse proxy.

It can:

serve static files
handle HTTP/HTTPS
route domains
forward PHP requests
act as reverse proxy
handle redirects
serve cached content

For your hosting platform:

Internet
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL

---

2. Nginx Is Not WordPress

This distinction is important.

Nginx
=
web server

while:

WordPress
=
web application

Nginx receives the network request.

WordPress generates the application response.

---

3. Static vs Dynamic

Suppose the browser requests:

/logo.png

Nginx may directly return the file:

Browser
 ↓
Nginx
 ↓
logo.png

No PHP required.

---

4. Dynamic Request

Now:

/about/

may require WordPress.

The flow becomes:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
PHP-FPM
 ↓
Nginx
 ↓
Browser

---

5. Nginx Master Process

When Nginx starts, there is normally a:

Master process

Its responsibilities include things such as:

read configuration
manage worker processes
handle signals
reload configuration

---

6. Worker Processes

Nginx also uses:

Worker processes

Workers handle network requests.

Conceptually:

Nginx
│
├── Master
│
├── Worker
├── Worker
├── Worker
└── Worker

The exact number depends on configuration and workload.

---

7. Check Nginx Processes

Run:

ps aux | grep nginx

You may see:

root      nginx: master process
www-data  nginx: worker process
www-data  nginx: worker process

The exact user and process details depend on your configuration.

---

8. Why Master Can Be Root

Nginx may start with elevated privileges so it can perform privileged operations such as binding to low-numbered ports.

Then worker processes can run with a less-privileged user.

This follows the same principle we studied earlier:

root
 ↓
privileged setup
 ↓
lower privilege workers

---

9. Low Ports

Ports below 1024 traditionally require elevated privileges to bind on Linux.

For example:

80
443

Therefore the master process may start with sufficient privilege to bind them.

Worker processes then handle requests with reduced privileges.

---

10. Configuration

Nginx’s main configuration is commonly:

/etc/nginx/nginx.conf

But your installation may include additional configuration directories.

Common structure:

/etc/nginx/
├── nginx.conf
├── sites-available/
├── sites-enabled/
├── conf.d/
└── ...

The exact layout depends on the distribution and installation.

---

11. Main Configuration

Check:

sudo nginx -t

This tests configuration syntax.

You can inspect the main file:

sudo nano /etc/nginx/nginx.conf

or:

sudo less /etc/nginx/nginx.conf

---

12. http Block

Nginx configuration has hierarchical blocks.

Conceptually:

http {
    server {
        ...
    }

    server {
        ...
    }
}

The http block contains HTTP configuration.

---

13. Server Block

A:

server

block represents a virtual server configuration.

For example:

server {
    listen 80;
    server_name example.com;
}

This is how Nginx can host multiple websites on one IP.

---

14. Multiple Websites

Suppose your server has:

203.0.113.25

and:

site1.com
site2.com
site3.com

All point to that IP.

Nginx can have:

server block 1
→ site1.com

server block 2
→ site2.com

server block 3
→ site3.com

---

15. server_name

The most important directive for virtual hosting is:

server_name site1.com www.site1.com;

This tells Nginx which hostnames the server block is intended to handle.

---

16. Example

server {
    listen 80;
    server_name learn.cresignsys.com;

    root /storage/websites/learn.cresignsys.com/public;
}

Now:

Host:
learn.cresignsys.com

can select this server block.

---

17. listen

This directive tells Nginx which address/port the server block listens on.

Example:

listen 80;

or HTTPS:

listen 443 ssl;

Modern configurations can also use additional directives for HTTP/2/HTTP/3 depending on Nginx version and configuration.

---

18. One Server, Many server Blocks

Example:

server {
    listen 80;
    server_name site1.com;

    root /storage/websites/site1.com/public;
}

server {
    listen 80;
    server_name site2.com;

    root /storage/websites/site2.com/public;
}

Both can use:

203.0.113.25:80

---

19. How Nginx Knows Which One?

The request contains the hostname.

For example:

Host: site2.com

Nginx searches its matching server configuration.

Conceptually:

Host: site2.com
        ↓
server_name site2.com
        ↓
site2 configuration

---

20. Default Server

What happens if no hostname matches?

Nginx uses the appropriate default server for that listen address/port.

Therefore, a request can sometimes display:

wrong website

even though DNS is correct.

This is a common hosting issue.

---

21. Example Problem

You configured:

siteA.com
siteB.com

But accidentally omitted:

server_name siteB.com;

Then:

siteB.com

may fall into another server block, potentially the default one.

---

22. root

The:

root

directive specifies the filesystem root for serving files.

Example:

root /storage/websites/site1.com/public;

Therefore:

URL:
/logo.png

Filesystem:
/storage/websites/site1.com/public/logo.png

for a direct static-file request, subject to Nginx location and rewrite rules.

---

23. Your Hosting Structure

Your current architecture is similar to:

/storage/websites/
│
├── learn.cresignsys.com/
│   └── public/
│
├── shop.cresignsys.com/
│   └── public/
│
├── manage.cresignsys.com/
│   └── public/
│
└── ...

This is a good foundation for a hosting platform.

---

24. Why public?

Keeping the web-accessible files inside:

public/

is useful.

For example:

site/
├── public/
│   ├── index.php
│   ├── wp-content/
│   └── ...
│
└── private/

Only:

public/

is exposed as the web root.

---

25. Security Benefit

Suppose your site has:

site/
├── public/
└── backups/

If Nginx root is:

site/public

then:

/backups/

is not automatically web-accessible.

This is much safer than making the entire site directory the document root.

---

26. location

Nginx uses:

location

blocks to control different URL paths.

Example:

location / {
    ...
}

means the general URL space.

---

27. Example

location /images/ {
    ...
}

can apply special behavior to:

/images/logo.png
/images/banner.jpg

---

28. Location Matching

Nginx has specific rules for choosing among multiple location blocks.

For example:

location / {
}

location /images/ {
}

location = /login {
}

The exact matching algorithm is important later.

For now remember:

location
=
URL-path processing rule

---

29. try_files

One of the most important directives for WordPress:

try_files

A common pattern is:

location / {
    try_files $uri $uri/ /index.php?$args;
}

---

30. What Does It Mean?

Conceptually:

Request
 ↓
Does the requested file exist?
 ↓
yes → serve it
 ↓
no
 ↓
Does the directory exist?
 ↓
yes → use it
 ↓
no
 ↓
send to index.php

This allows WordPress’s pretty URLs to work.

---

31. WordPress Pretty URL

Browser requests:

/about/

There may be no physical:

/about/index.html

Instead:

/about/
 ↓
index.php
 ↓
WordPress
 ↓
About page

---

32. Front Controller

This architecture is called a:

Front Controller

WordPress commonly uses:

index.php

as the central entry point.

So many URLs eventually reach:

index.php

---

33. PHP Location

Nginx needs a rule for PHP.

Conceptually:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

The exact socket path depends on your PHP-FPM installation.

---

34. FastCGI

Nginx does not execute PHP itself.

Instead:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM

FastCGI is a protocol/interface for communicating with application processes such as PHP-FPM.

---

35. PHP-FPM

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

Conceptually:

Nginx
   │
   ▼
PHP-FPM
   │
   ├── PHP worker
   ├── PHP worker
   ├── PHP worker
   └── PHP worker

---

36. Nginx Doesn’t Run PHP

This is worth memorizing:

Nginx
≠
PHP

Nginx handles:

HTTP
static files
proxying
routing

PHP-FPM handles:

PHP execution

---

37. Static Request

For:

/logo.png

the flow can be:

Browser
 ↓
Nginx
 ↓
/public/logo.png
 ↓
Browser

---

38. PHP Request

For:

/index.php

the flow can be:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
PHP
 ↓
Nginx
 ↓
Browser

---

39. WordPress Request

For:

/about/

the flow is often:

Browser
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
PHP
 ↓
Nginx
 ↓
Browser

---

40. One Server, Multiple PHP-FPM Pools

For professional hosting, you can eventually configure:

PHP-FPM
│
├── site1 pool → user1
├── site2 pool → user2
├── site3 pool → user3
└── ...

This provides better isolation than having every site share one PHP execution identity.

---

41. Site-Specific Socket

Each PHP-FPM pool can have its own socket.

Conceptually:

site1
 ↓
/run/php/site1.sock

site2
 ↓
/run/php/site2.sock

Nginx can then route each site’s PHP requests to its own pool.

---

42. Why This Is Powerful

Suppose:

site1

gets heavy traffic.

You can configure its PHP-FPM pool separately from:

site2

You can control things such as:

worker limits
process management
user
group
socket

---

43. Resource Isolation

This leads to a professional architecture:

siteA
 ↓
userA
 ↓
PHP pool A
 ↓
socket A

siteB
 ↓
userB
 ↓
PHP pool B
 ↓
socket B

Now sites are more strongly separated.

---

44. Your CresignSys Hosting Platform

Your automation can eventually create:

CREATE WEBSITE
       │
       ├── domain
       ├── directory
       ├── user
       ├── group
       ├── PHP-FPM pool
       ├── socket
       ├── Nginx server block
       ├── database
       ├── database user
       ├── DNS
       └── SSL

This is the architecture you are gradually building toward.

---

45. Nginx Configuration Generation

For:

learn.cresignsys.com

your automation could generate a configuration conceptually like:

server {
    listen 80;
    server_name learn.cresignsys.com;

    root /storage/websites/learn.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/learn.cresignsys.com.sock;
    }
}

This is a simplified teaching example; production configurations need additional security and PHP-FPM parameters.

---

46. Why Configuration Templates Matter

Imagine manually configuring:

1 website

Not too difficult.

But:

10 websites

becomes repetitive.

At:

100 websites

manual configuration becomes error-prone.

Therefore:

Template
+
Automation

becomes essential.

---

47. Your Hosting Script

Your hosting creation system can receive:

DOMAIN=example.com

and generate:

/storage/websites/example.com/public

then:

Nginx configuration
PHP-FPM pool
database
permissions
SSL

---

48. The Hosting Control Plane

This introduces an important concept:

Control Plane

Your management system decides:

What websites exist?
Who owns them?
Where are they stored?
Which PHP version?
Which database?
Which domain?
Which SSL certificate?

---

49. Data Plane

The actual traffic path is the:

Data Plane

Internet
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Your control panel manages the configuration.

The web stack serves the traffic.

---

50. Example

Your hosting platform might have:

Control Plane
       │
       ▼
Create Website
       │
       ├── Nginx config
       ├── PHP-FPM config
       ├── database
       └── SSL
       
Data Plane
       │
       ▼
Internet
       ↓
Nginx
       ↓
PHP
       ↓
WordPress

This distinction becomes very important when designing a real hosting service.

---

51. Nginx Reload

After generating configuration:

sudo nginx -t

First.

If successful:

sudo systemctl reload nginx

Never make blind configuration changes and immediately restart the server without testing the configuration.

---

52. Why nginx -t Is Important

Suppose your script generates:

server_name example.com

but forgets:

;

Nginx configuration becomes invalid.

If you reload blindly:

reload failure

could affect your hosting service.

Therefore:

Generate
 ↓
Validate
 ↓
Reload

---

53. Safe Automation Pattern

Your hosting script should conceptually do:

1. Validate domain
        ↓
2. Create directories
        ↓
3. Create user
        ↓
4. Set permissions
        ↓
5. Create PHP-FPM configuration
        ↓
6. Create Nginx configuration
        ↓
7. nginx -t
        ↓
8. Reload Nginx
        ↓
9. Configure database
        ↓
10. Configure SSL

Error handling becomes critical.

---

54. Nginx Logs

Common log directory:

/var/log/nginx/

You may find:

access.log
error.log

or per-site logs if your configuration defines them.

---

55. Access Log

An access log answers:

Did Nginx receive the request?

You may see:

GET /about/ HTTP/2
200

---

56. Error Log

The error log answers:

Did Nginx encounter a problem?

Examples:

permission denied
connect() failed
upstream timed out
no such file

---

57. Nginx + Permissions

Remember the previous lesson.

Nginx needs filesystem access.

If:

/storage/websites/example.com/public

cannot be traversed by the Nginx worker user, you may get:

403 Forbidden

---

58. Nginx + PHP-FPM

If:

Nginx
 ↓
PHP-FPM socket

is inaccessible:

502 Bad Gateway

may occur.

So permissions also apply to:

/run/php/

and the PHP-FPM socket.

---

59. Socket Permissions

Suppose:

/run/php/site.sock

belongs to:

siteuser:www-data

and has restrictive permissions.

Nginx must be able to access the socket.

Otherwise:

Nginx
 ↓
cannot connect
 ↓
502

---

60. This Connects Three Lessons

We now have:

Networking

TCP 443

Nginx

server_name
root
location

Linux permissions

user
group
socket/file permissions

These aren’t separate topics.

They interact.

---

61. Example Failure

Suppose:

DNS ✓
TCP 443 ✓
Nginx ✓

but:

Nginx → PHP-FPM socket ✗

Result:

502 Bad Gateway

The problem isn’t DNS.

It isn’t the domain.

It isn’t WordPress.

It is the Nginx-to-PHP-FPM layer.

---

62. Another Failure

Suppose:

DNS ✓
TCP ✓
Nginx ✓
PHP-FPM ✓

but:

WordPress directory
permissions ✗

Result may be:

403
500
file access errors

depending on exactly what operation failed.

---

63. Another Failure

Suppose everything works except:

MySQL

Then PHP may produce:

database connection error

The HTTP server is functioning.

The application backend isn’t.

---

64. Layered Architecture

Your complete website is now:

┌─────────────────────────────┐
│          INTERNET           │
└──────────────┬──────────────┘
               ↓
             DNS
               ↓
          Public IP
               ↓
        OCI Networking
               ↓
            TCP 443
               ↓
             Nginx
               ↓
        ┌──────┴──────┐
        ↓             ↓
   Static files     PHP-FPM
                      ↓
                  WordPress
                      ↓
                    MySQL

And:

Users
Groups
Permissions

control filesystem/process access underneath.

---

65. The Most Important Nginx Directives

For your current level, memorize these:

listen
server_name
root
index
location
try_files
include
fastcgi_pass

---

66. Their Meaning

listen
→ Which network endpoint?

server_name
→ Which domain?

root
→ Which filesystem directory?

index
→ Which default files?

location
→ Which URL rules?

try_files
→ Does the requested resource exist?

include
→ Load reusable configuration

fastcgi_pass
→ Where should PHP requests go?

---

67. One Website

learn.cresignsys.com
        ↓
Nginx
        ↓
/storage/websites/learn.cresignsys.com/public
        ↓
PHP-FPM
        ↓
WordPress

---

68. Ten Websites

Nginx
│
├── site1.com → PHP-FPM 1
├── site2.com → PHP-FPM 2
├── site3.com → PHP-FPM 3
├── site4.com → PHP-FPM 4
├── site5.com → PHP-FPM 5
└── ...

This is the foundation of a hosting server.

---

69. Hundreds of Websites

At larger scale:

Internet
    ↓
Load Balancer / Edge
    ↓
Web Servers
    ↓
PHP/Application Layer
    ↓
Database/Cache/Storage

A single VPS can host multiple sites, but at larger scale you start separating services and workloads.

---

70. Lesson 059 — Core Principle

The central idea is:

Nginx is the traffic director at the web-server layer.

It receives:

IP
 ↓
Port
 ↓
HTTP request

and determines:

Which domain?
 ↓
Which server block?
 ↓
Which URL rule?
 ↓
Static file or PHP?
 ↓
Which PHP-FPM backend?

That is the foundation of multi-domain hosting.

---

Next Lesson — 060

PHP-FPM Deep Dive — How Nginx Runs WordPress PHP

Next we go one level deeper:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
Master process
 ↓
Worker pool
 ↓
PHP execution
 ↓
WordPress

We will learn:

PHP-FPM pools
users
groups
Unix sockets
TCP sockets
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests
memory usage
slow requests
502 errors

and how to design one PHP-FPM pool per website for your CresignSys hosting platform.

HTTP Deep Dive — How a Web Request Actually Works

We now know:

Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
Port 443
 ↓
Nginx

Now we need to understand what happens after the browser reaches Nginx.

That is the job of:

HTTP

---

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

It is the protocol used for communication between a web client and a web server.

Simplified:

Browser
   ↓
HTTP Request
   ↓
Web Server
   ↓
HTTP Response
   ↓
Browser

---

2. HTTPS

When HTTP is protected by TLS:

HTTP
 +
TLS
 =
HTTPS

So:

http://example.com

normally uses:

TCP 80

while:

https://example.com

normally uses:

TCP 443

---

3. The First Request

Suppose you open:

https://learn.cresignsys.com/about/

After DNS and the network connection are established, the browser sends an HTTP request.

Conceptually:

GET /about/ HTTP/1.1
Host: learn.cresignsys.com

There are additional headers in a real browser request.

---

4. HTTP Request

An HTTP request contains several important parts:

Request
├── Method
├── URL/path
├── Headers
└── Body

For example:

GET /about/

is the main request line.

---

5. HTTP Methods

The most important HTTP methods are:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

For basic WordPress hosting, start with:

GET
POST

---

6. GET

GET generally means:

Give me this resource.

Example:

GET /about/

The browser is asking the server for the About page.

---

7. Another GET

For:

https://learn.cresignsys.com/contact/

the request may be:

GET /contact/ HTTP/1.1
Host: learn.cresignsys.com

---

8. POST

POST is commonly used to send data to the server.

For example:

Login form
Contact form
WordPress admin login
Comment submission

A simplified request:

POST /wp-login.php HTTP/1.1

The submitted data is normally in the request body.

---

9. Request Body

For example, a form submission might contain data such as:

username=admin
password=...

The actual request encoding and security depend on the application.

With HTTPS, the network transport is encrypted.

---

10. HTTP Headers

Headers provide additional information.

Example:

Host: learn.cresignsys.com
User-Agent: ...
Accept: text/html
Accept-Encoding: gzip, br

Headers tell the server about the request and tell the client how to interpret the response.

---

11. Host Header

This is extremely important for hosting.

Suppose the same VPS hosts:

siteA.com
siteB.com
siteC.com

All have:

203.0.113.25

The browser sends:

Host: siteB.com

Nginx can then choose the appropriate website.

---

12. Virtual Hosting

Therefore:

203.0.113.25
      │
      ├── siteA.com
      ├── siteB.com
      └── siteC.com

is possible.

Nginx uses hostname information to route the request to the correct server configuration.

---

13. Nginx Server Block

A simplified configuration:

server {
    listen 443 ssl;
    server_name siteB.com www.siteB.com;

    root /storage/websites/siteB.com/public;
}

The important relationship is:

Host: siteB.com
        ↓
server_name siteB.com
        ↓
document root

---

14. URL Structure

Consider:

https://learn.cresignsys.com/blog/post-1/?page=2

Break it down:

https://
learn.cresignsys.com
/blog/post-1/
?page=2

These components have different purposes.

---

15. Scheme

https://

is the scheme.

It tells the client to use HTTPS.

---

16. Host

learn.cresignsys.com

is the hostname.

DNS resolves this hostname.

---

17. Path

/blog/post-1/

is the path.

It identifies the requested resource within the website.

---

18. Query String

?page=2

is the query string.

It passes additional parameters.

Example:

/search/?q=wordpress

Here:

q=wordpress

is a query parameter.

---

19. Fragment

You might see:

/about/#services

The:

#services

is a URL fragment.

Normally, the fragment is handled by the browser and is not sent to the server as part of the HTTP request.

This distinction is important.

---

20. Complete URL

https://learn.cresignsys.com/about/?lang=en#history

Breakdown:

Scheme:
https

Host:
learn.cresignsys.com

Path:
/about/

Query:
lang=en

Fragment:
history

---

21. HTTP Response

After receiving the request, the server responds.

Example:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: ...

Then comes the response body:

<html>
...
</html>

---

22. Response Structure

An HTTP response contains:

Response
├── Status code
├── Headers
└── Body

---

23. Status Codes

HTTP status codes are grouped into categories:

1xx
2xx
3xx
4xx
5xx

You should memorize the most important ones.

---

24. 200

200 OK

means the request was successfully handled.

Example:

GET /
 ↓
200 OK

---

25. 201

201 Created

means a resource was successfully created.

This is common in APIs.

---

26. 204

204 No Content

means the request succeeded but there is no response body to return.

---

27. 301

301 Moved Permanently

indicates a permanent redirect.

Example:

http://example.com
        ↓
301
        ↓
https://example.com

---

28. 302

302 Found

is commonly used for temporary redirects.

Redirect behavior is more nuanced across HTTP versions and applications, but the key idea is:

server
 ↓
redirect
 ↓
another URL

---

29. 304

304 Not Modified

is used with caching.

It tells the browser that the cached representation can still be used when the request conditions allow it.

---

30. 400

400 Bad Request

means the server considers the request malformed or invalid.

---

31. 401

401 Unauthorized

means authentication is required or failed.

Despite the name, this generally means:

Authentication is needed.

---

32. 403

403 Forbidden

means the server understood the request but refuses to authorize access.

Common causes:

permission
access rules
directory restrictions
application authorization

---

33. 404

404 Not Found

means the requested resource could not be found.

For example:

GET /does-not-exist/

may return:

404 Not Found

---

34. 405

405 Method Not Allowed

means the resource exists but does not allow the HTTP method used.

---

35. 408

408 Request Timeout

indicates the server timed out waiting for the request.

---

36. 429

429 Too Many Requests

usually means rate limiting has been triggered.

This can be generated by:

Nginx
application
CDN
API gateway
security layer

---

37. 500

500 Internal Server Error

means the server encountered an unexpected error.

For WordPress, possible causes include:

PHP error
plugin error
theme error
configuration error

---

38. 502

502 Bad Gateway

is particularly important in your hosting environment.

It often means a proxy such as Nginx could not obtain a valid response from its upstream service.

For WordPress:

Nginx
 ↓
PHP-FPM

If PHP-FPM is unavailable or misconfigured, you may get:

502

---

39. 503

503 Service Unavailable

means the server is currently unable to handle the request.

Possible reasons include:

overload
maintenance
upstream unavailable
application limits

---

40. 504

504 Gateway Timeout

means a gateway/proxy waited too long for an upstream response.

Example:

Nginx
 ↓
PHP-FPM
 ↓
MySQL

If the upstream operation takes too long, a timeout can occur.

---

41. Status Code Troubleshooting

Memorize this table:

Code	Meaning	Hosting clue
200	OK	Working
301	Permanent redirect	URL redirect
302	Temporary redirect	Redirect
304	Not modified	Cache
400	Bad request	Invalid request
401	Authentication required	Login/auth
403	Forbidden	Access/permissions
404	Not found	URL/resource
429	Too many requests	Rate limit
500	Server error	PHP/application
502	Bad gateway	PHP-FPM/upstream
503	Unavailable	Service/load
504	Gateway timeout	Slow upstream

---

42. curl

For web hosting, curl is one of your most important tools.

Test:

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

The -I option requests headers without downloading the full body in the usual way.

---

43. Example

You may see:

HTTP/2 200
server: nginx
content-type: text/html

Now you know:

DNS ✓
network ✓
TLS ✓
Nginx ✓
HTTP ✓

at least at a basic level.

---

44. Follow Redirects

Use:

curl -IL https://learn.cresignsys.com

The:

-L

option follows redirects.

You may see:

301
 ↓
https://...
 ↓
200

---

45. See More Details

Use:

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

This can show details about:

DNS connection
TCP connection
TLS
HTTP request
HTTP response

It is extremely useful for troubleshooting.

---

46. TLS + HTTP

When you run:

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

you can see the stages:

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

This connects our previous lessons together.

---

47. HTTP Headers

Some important response headers include:

Content-Type
Content-Length
Cache-Control
Location
Set-Cookie
Server
ETag
Last-Modified

---

48. Content-Type

Example:

Content-Type: text/html

means the body is HTML.

Other examples:

text/css
application/javascript
application/json
image/jpeg
image/png

---

49. Why Content-Type Matters

The browser uses the content type to determine how to interpret the response.

For example:

text/html

→ render as HTML.

image/png

→ interpret as PNG image.

---

50. Content-Length

Example:

Content-Length: 48291

This indicates the size of the response body in bytes in contexts where this header is used.

---

51. Cache-Control

Example:

Cache-Control: max-age=3600

This provides caching instructions.

Caching is extremely important for hosting performance.

---

52. Browser Cache

Suppose your website contains:

style.css
logo.png
script.js

Downloading them repeatedly wastes resources.

The browser can cache them.

Therefore:

First visit
 ↓
download
 ↓
cache

Later:

visit
 ↓
use cache

when the caching rules permit.

---

53. Server Cache

You can also cache on the server side.

For WordPress:

Browser
 ↓
Nginx
 ↓
cache
 ↓
HTML

can avoid invoking PHP for every request.

---

54. WordPress Without Cache

A request may look like:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
WordPress
 ↓
PHP
 ↓
Nginx
 ↓
Browser

This involves significant processing.

---

55. WordPress With Page Cache

With an effective page cache:

Browser
 ↓
Nginx
 ↓
cached HTML
 ↓
Browser

The PHP/MySQL path can sometimes be avoided for cacheable requests.

---

56. Why This Matters for Hosting

Suppose you host:

100 websites

and each receives many requests.

If every request reaches:

PHP
+
MySQL

resource consumption can become substantial.

Caching can dramatically reduce backend work.

---

57. Cookies

HTTP can use:

Cookies

A server can send:

Set-Cookie: session=...

The browser stores the cookie according to its attributes and policies.

Later requests can include:

Cookie: session=...

---

58. Why WordPress Uses Cookies

WordPress uses cookies for functionality such as:

login
authentication
preferences
sessions

---

59. Login Example

Simplified:

Browser
 ↓
POST /wp-login.php
 ↓
WordPress
 ↓
authentication
 ↓
Set-Cookie
 ↓
Browser

Then:

Browser
 ↓
Cookie
 ↓
WordPress

allows WordPress to recognize the authenticated session.

---

60. HTTP Is Stateless

HTTP itself is fundamentally stateless.

That means each request can be processed independently.

Cookies and application-level session mechanisms allow applications to maintain continuity between requests.

---

61. Example

Without session information:

Request 1
Who are you?

Request 2
Who are you?

Request 3
Who are you?

With authentication cookies:

Request
 ↓
Cookie
 ↓
User identified

---

62. Security Attributes of Cookies

Important cookie attributes include:

Secure
HttpOnly
SameSite

Secure

Cookie should be sent over secure connections.

HttpOnly

Helps prevent client-side JavaScript from directly reading the cookie.

SameSite

Controls cross-site cookie sending behavior.

---

63. HTTP Compression

Web servers can compress responses.

Common compression mechanisms include:

gzip
Brotli

Example:

HTML
 ↓
compression
 ↓
smaller transfer
 ↓
browser
 ↓
decompression

---

64. Why Compression Helps

Suppose:

HTML = 500 KB

Compression might reduce the transferred size significantly.

Less data means:

less bandwidth
faster transfer

depending on network conditions and content.

---

65. HTTP/1.1

Traditional HTTP/1.1 uses textual requests and responses.

Example:

GET / HTTP/1.1
Host: example.com

It is still widely supported.

---

66. HTTP/2

HTTP/2 improves how multiple requests can be transported over a connection.

It supports concepts such as:

multiplexing
header compression
binary framing

---

67. HTTP/2 Multiplexing

Instead of treating requests as completely independent serial transfers at the HTTP layer, HTTP/2 can multiplex multiple streams over one connection.

Conceptually:

TCP connection
│
├── HTML stream
├── CSS stream
├── JS stream
├── image stream
└── API stream

This can improve efficiency.

---

68. HTTP/3

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP

rather than the traditional:

HTTP/2
 ↓
TLS
 ↓
TCP

HTTP/3 is an advanced topic, but it is useful to know that modern web hosting can involve it.

---

69. Your Nginx Server

Nginx can be configured to support modern HTTP versions depending on the build and configuration.

You don’t need to enable every feature immediately.

For your hosting platform, first make:

HTTP/1.1 or HTTP/2
+
HTTPS
+
PHP-FPM
+
WordPress

reliable.

---

70. HTTP Request to WordPress

Now let’s follow:

https://learn.cresignsys.com/about/

---

71. Step 1

Browser performs DNS:

learn.cresignsys.com
        ↓
IP

---

72. Step 2

Browser establishes network connectivity:

TCP
 ↓
443

---

73. Step 3

TLS handshake:

Browser
 ↕
Nginx

Certificate is validated according to the browser’s trust rules.

---

74. Step 4

Browser sends:

GET /about/ HTTP/2
Host: learn.cresignsys.com

The exact wire representation differs with HTTP/2, but conceptually this is the request.

---

75. Step 5

Nginx receives it.

Nginx examines:

Host
Path
Method
Headers

---

76. Step 6

Nginx determines:

server_name

matches:

learn.cresignsys.com

---

77. Step 7

Nginx determines the requested resource.

For a typical WordPress setup, a pretty URL such as:

/about/

may not correspond to a physical directory named:

/about/

---

78. WordPress Front Controller

WordPress commonly uses:

index.php

as its front controller.

Conceptually:

/about/
   ↓
Nginx rewrite
   ↓
index.php
   ↓
WordPress

---

79. Typical Nginx Concept

A WordPress configuration often contains logic conceptually similar to:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Meaning:

Does the file exist?
        │
     yes│no
        ▼
serve file
        │
        └────→ index.php

The exact configuration should be adapted to your PHP-FPM and site architecture.

---

80. PHP-FPM

If Nginx determines the request needs PHP:

Nginx
 ↓
PHP-FPM

Nginx communicates with PHP-FPM through a configured FastCGI interface.

Commonly this is:

Unix socket

or:

TCP socket

---

81. Unix Socket

You may see something like:

/run/php/php8.x-fpm.sock

The exact PHP version and socket path depend on your installation.

Nginx uses the configured socket to communicate with PHP-FPM.

---

82. PHP-FPM Executes WordPress

PHP-FPM receives:

index.php

and executes PHP.

WordPress loads:

core
themes
plugins
configuration

and eventually queries MySQL where required.

---

83. MySQL

WordPress might execute database queries such as:

SELECT ...

The database returns:

posts
pages
users
settings
metadata

---

84. WordPress Generates HTML

PHP combines:

WordPress core
+
theme
+
plugins
+
database data

and produces an HTML response.

---

85. Response Returns

The flow reverses:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Internet
 ↓
Browser

---

86. Browser Receives HTML

The browser parses:

<html>
<head>
...
</head>
<body>
...
</body>
</html>

But the page usually contains references to additional resources.

For example:

CSS
JavaScript
images
fonts

---

87. Additional Requests

The browser may then request:

/style.css
/script.js
/logo.png
/font.woff2

So one page load can create many HTTP requests.

Conceptually:

HTML
 ├── CSS request
 ├── JS request
 ├── image request
 ├── font request
 └── API request

---

88. Why Websites Can Be Slow

A page may require:

1 HTML request
+
10 CSS/JS requests
+
50 images
+
5 fonts
+
API calls

Now the server handles many operations.

This is why:

caching
compression
CDN
image optimization
HTTP/2

matter.

---

89. Inspect Your Website

Run:

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

Then:

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

You are now capable of understanding much more of the output.

---

90. Check the Status

For example:

HTTP/2 200

means the HTTP exchange succeeded.

If you see:

HTTP/2 301

you know a redirect occurred.

If:

HTTP/2 502

look toward the Nginx → PHP-FPM/upstream layer.

---

91. Check Headers

Look for:

server:
content-type:
cache-control:
location:
set-cookie:

These give clues about how your site is operating.

---

92. Browser Developer Tools

Open your browser’s Developer Tools:

F12

Then:

Network

Reload the website.

You will see requests such as:

/
about/
style.css
script.js
logo.png

---

93. Network Tab

For each request you can inspect:

Status
Method
Domain
Path
Size
Time
Response headers
Request headers

This is one of the most useful tools for web hosting troubleshooting.

---

94. Example

Suppose:

/about/
200

but:

/style.css
404

The WordPress page itself works, but the CSS path is wrong.

---

95. Another Example

Suppose:

/about/
200

but:

/wp-content/uploads/image.jpg
403

Now investigate:

file permissions
directory permissions
Nginx rules
security rules

---

96. Another Example

Suppose:

/about/
502

Then investigate:

Nginx
 ↓
PHP-FPM

Check:

sudo systemctl status php*-fpm

and inspect relevant logs.

---

97. Logs

Your hosting platform must eventually teach you:

access logs
error logs
PHP logs
MySQL logs
system logs

For Nginx, common locations include:

/var/log/nginx/

The exact log configuration can differ.

---

98. Access Log

An access log records requests.

Conceptually:

client IP
timestamp
request
status
bytes
user agent

Example:

GET /about/ HTTP/2
200

This answers:

Did the request actually reach Nginx?

---

99. Error Log

The error log can show:

permission problems
upstream failures
configuration errors
connection errors

This answers:

What went wrong while processing the request?

---

100. The Hosting Troubleshooting Map

At this point you can diagnose:

Domain doesn't resolve
 ↓
DNS

Domain resolves but connection times out
 ↓
network/security

Connection refused
 ↓
listener/firewall/service

Nginx returns 404
 ↓
routing/document root/rewrite

Nginx returns 403
 ↓
permissions/access rules

Nginx returns 502
 ↓
PHP-FPM/upstream

WordPress returns 500
 ↓
PHP/plugin/theme/application

Database errors
 ↓
MySQL/WordPress database layer

---

101. Lesson 058 — Core Principle

The key idea is:

HTTP is the conversation between the browser and your web server.

The complete request path is now:

Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
TLS
 ↓
HTTP Request
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTTP Response
 ↓
Browser

You are now moving from server administration into actual web-server engineering.

---

Next Lesson — 059

Nginx Deep Dive — How One Server Hosts Hundreds of Websites

We will build the next layer:

Nginx
 ↓
Master process
 ↓
Worker processes
 ↓
server blocks
 ↓
server_name
 ↓
listen
 ↓
root
 ↓
location
 ↓
try_files
 ↓
FastCGI
 ↓
PHP-FPM

Then we will connect it directly to your structure:

/storage/websites/
├── domain1.com/
├── domain2.com/
├── domain3.com/
└── ...

and design the architecture needed to turn your current server into a multi-domain hosting platform.

DNS Deep Dive — From Domain Name to Your VPS

We now go one layer deeper.

You already understand:

Browser
 ↓
Domain
 ↓
DNS
 ↓
IP
 ↓
Network
 ↓
Port 443
 ↓
Nginx
 ↓
WordPress

The question now is:

How does DNS actually turn learn.cresignsys.com into an IP address?

---

1. Domain Name Is Not the Server

When you type:

learn.cresignsys.com

your computer does not initially know where that server is.

It needs DNS.

Think:

learn.cresignsys.com
        ↓
      DNS
        ↓
   IP address
        ↓
      server

---

2. DNS Means Domain Name System

DNS is essentially a distributed naming system.

It maps names to information such as:

domain → IPv4 address
domain → IPv6 address
domain → mail server
domain → another domain

and more.

---

3. Why DNS Exists

Humans prefer:

learn.cresignsys.com

Computers ultimately need network addresses such as:

203.0.113.25

So DNS provides the translation mechanism.

---

4. Domain Hierarchy

Look at:

learn.cresignsys.com

Break it apart:

learn
   .
cresignsys
   .
com

There is also an invisible final dot:

learn.cresignsys.com.

That final dot represents the DNS root.

---

5. DNS Root

At the top is:

.

called the:

Root

Below the root are:

com
org
net
in
...

These are:

TLDs

Top-Level Domains.

---

6. TLD

For:

cresignsys.com

the TLD is:

com

For:

example.in

the TLD is:

in

---

7. Domain

In:

learn.cresignsys.com

the registered domain is:

cresignsys.com

and:

learn

is a subdomain label.

---

8. Subdomain

Therefore:

learn.cresignsys.com

means approximately:

learn
 ↓
cresignsys.com
 ↓
com
 ↓
root

The DNS hierarchy works from right to left.

---

9. Example

Consider:

shop.cresignsys.com

Hierarchy:

.
└── com
    └── cresignsys
        └── shop

---

10. Root Servers

The DNS root system points resolvers toward the appropriate TLD name servers.

Conceptually:

Resolver
   ↓
Root
   ↓
.com servers
   ↓
cresignsys.com authoritative servers
   ↓
shop.cresignsys.com

---

11. TLD Servers

The .com infrastructure knows which authoritative nameservers are responsible for:

cresignsys.com

It doesn’t necessarily contain the final IP address for every subdomain.

It directs the resolver to the authoritative DNS service for the domain.

---

12. Authoritative Nameserver

The authoritative DNS server is the source of truth for the DNS zone.

For example:

cresignsys.com
      ↓
authoritative nameserver
      ↓
DNS records

---

13. DNS Zone

A DNS zone contains records such as:

A
AAAA
CNAME
MX
TXT
NS
CAA

and others.

---

14. A Record

The most important record for basic web hosting:

A

It maps a hostname to an IPv4 address.

Conceptually:

learn.cresignsys.com
        ↓
A
        ↓
203.0.113.25

---

15. Example

A DNS zone might contain:

learn     A     203.0.113.25

This means:

learn.cresignsys.com
        ↓
203.0.113.25

assuming learn is within the cresignsys.com zone.

---

16. AAAA Record

For IPv6:

AAAA

Example:

learn.cresignsys.com
        ↓
AAAA
        ↓
2001:db8::25

---

17. A vs AAAA

Remember:

A
=
IPv4

AAAA
=
IPv6

---

18. Why IPv6 Can Cause Confusion

Suppose you configure:

A
↓
correct IPv4

but also have:

AAAA
↓
incorrect IPv6

Some clients may attempt IPv6 connectivity and encounter problems.

Then you might see:

Website works on one network
Website fails on another

even though the IPv4 configuration is correct.

---

19. CNAME

Another important record:

CNAME

It maps one hostname to another hostname.

Example:

www.cresignsys.com
        ↓
CNAME
        ↓
cresignsys.com

Conceptually:

www
 ↓
cresignsys.com
 ↓
A/AAAA
 ↓
IP

---

20. CNAME Is Not an IP Address

An A record contains:

hostname → IPv4

A CNAME contains:

hostname → hostname

This distinction matters.

---

21. Example

You might configure:

shop.cresignsys.com
A
203.0.113.25

and:

www.shop.cresignsys.com
CNAME
shop.cresignsys.com

Then:

www.shop.cresignsys.com
 ↓
shop.cresignsys.com
 ↓
203.0.113.25

---

22. MX Record

MX means:

Mail Exchange

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

Example concept:

cresignsys.com
 ↓
MX
 ↓
mail.example.com

This is for email, not normal website traffic.

---

23. TXT Record

TXT records store text-based DNS information.

They are commonly used for:

domain verification
SPF
DKIM-related records
DMARC-related records
other verification/configuration

---

24. NS Record

NS means:

Name Server

It identifies authoritative nameservers for a DNS zone.

Conceptually:

cresignsys.com
 ↓
NS
 ↓
ns1.example-dns.com
ns2.example-dns.com

---

25. CAA Record

CAA records can specify which certificate authorities are authorized to issue certificates for a domain.

This is useful for controlling certificate issuance.

---

26. TTL

TTL means:

Time To Live

It tells DNS resolvers how long a record may be cached.

Example:

A record
TTL = 3600

means roughly:

3600 seconds
=
1 hour

for caching purposes.

---

27. Why DNS Changes Don’t Always Appear Immediately

Suppose you change:

A record
old IP
 ↓
new IP

Some DNS resolvers may still have the old value cached until its TTL expires.

Therefore:

Your computer
 ↓
old cached DNS

while:

another user
 ↓
new DNS

can temporarily happen.

---

28. DNS Is Distributed

There isn’t one single DNS server containing everything.

Instead:

Browser
 ↓
Recursive resolver
 ↓
DNS hierarchy
 ↓
Authoritative server

and cached answers are used where appropriate.

---

29. Recursive Resolver

Your computer usually asks a:

Recursive DNS Resolver

For example, a resolver operated by:

ISP
public DNS provider
enterprise network
local network

The resolver does the work of finding the answer.

---

30. Typical Query

Your computer asks:

What is the IP of learn.cresignsys.com?

The recursive resolver checks its cache.

If it doesn’t have a valid cached answer, it resolves the name.

---

31. Simplified Resolution

Conceptually:

Client
 ↓
Recursive Resolver
 ↓
Root
 ↓
.com
 ↓
cresignsys.com authoritative DNS
 ↓
A record
 ↓
IP

The resolver then returns the answer to the client.

---

32. Caching

Suppose:

learn.cresignsys.com
A
203.0.113.25
TTL 3600

A recursive resolver can cache that result.

The next user asking the same resolver may receive the cached answer without the resolver querying the authoritative server again.

---

33. Why Caching Is Useful

Without caching:

every request
 ↓
DNS hierarchy

With caching:

request
 ↓
local resolver cache
 ↓
answer

This greatly reduces DNS traffic and improves speed.

---

34. Local DNS Cache

Your own computer, browser, operating system, router, or network resolver may also cache DNS responses.

So sometimes:

DNS changed

but:

your computer

still has an older answer cached.

---

35. dig

One of the best DNS troubleshooting tools is:

dig

Example:

dig learn.cresignsys.com

---

36. Short Answer

Use:

dig +short learn.cresignsys.com

Example:

203.0.113.25

This gives you the returned IP address directly.

---

37. Query A Specifically

dig A learn.cresignsys.com

---

38. Query AAAA

dig AAAA learn.cresignsys.com

This checks IPv6.

---

39. Query CNAME

dig CNAME www.cresignsys.com

---

40. Query MX

dig MX cresignsys.com

---

41. Query NS

dig NS cresignsys.com

---

42. Query TXT

dig TXT cresignsys.com

---

43. Different DNS Resolvers

You can ask a specific DNS resolver.

For example:

dig @8.8.8.8 learn.cresignsys.com

This asks Google’s public resolver.

You can also use another resolver such as:

dig @1.1.1.1 learn.cresignsys.com

The returned results can sometimes differ temporarily because of caching or propagation.

---

44. Authoritative Server Directly

You can investigate authoritative DNS using:

dig NS cresignsys.com

Then query an authoritative server directly:

dig @AUTHORITATIVE_SERVER learn.cresignsys.com

This helps distinguish:

authoritative DNS

from:

cached recursive DNS

---

45. +trace

A very useful advanced command:

dig +trace learn.cresignsys.com

This walks through DNS delegation.

Conceptually:

root
 ↓
.com
 ↓
cresignsys.com
 ↓
learn.cresignsys.com

This is excellent for understanding DNS deeply.

---

46. DNS Delegation

Suppose you register:

cresignsys.com

with a registrar.

The registrar records which nameservers are authoritative for your domain.

For example:

cresignsys.com
 ↓
NS
 ↓
DNS provider

---

47. Registrar vs DNS Provider

These are different concepts.

Registrar

Manages your domain registration.

DNS provider

Hosts/manages the DNS zone.

They can be:

same company

or:

different companies

---

48. Example

You might:

buy domain
 ↓
registrar

but use:

DNS
 ↓
Cloudflare

or another DNS provider.

The registrar points the domain delegation to the DNS provider’s nameservers.

---

49. Nameserver Change

Suppose your domain currently uses:

DNS Provider A

and you change nameservers to:

DNS Provider B

Then the authoritative source changes.

The DNS records you configured at Provider A may no longer control the domain.

This is a common source of confusion.

---

50. Important Hosting Principle

Before editing DNS, determine:

Who is authoritative for the domain?

Run:

dig NS cresignsys.com

---

51. Domain vs Subdomain

If you have:

cresignsys.com

you can create:

learn.cresignsys.com
shop.cresignsys.com
manage.cresignsys.com

These are different DNS names.

---

52. Wildcard DNS

You can also use a wildcard record:

*.cresignsys.com

For example:

*.cresignsys.com
A
203.0.113.25

This can cause many otherwise-unconfigured subdomains to resolve to the same IP, subject to DNS rules and any more-specific records.

---

53. Why Wildcard DNS Can Be Useful for Hosting

Imagine your hosting platform creates:

site1.cresignsys.com
site2.cresignsys.com
site3.cresignsys.com

A wildcard can reduce the need to create an individual DNS A record for every subdomain under a controlled zone.

However, for customer-owned domains such as:

customer.com

the customer still needs appropriate DNS configuration at their domain.

---

54. DNS Doesn’t Configure Nginx

This is extremely important.

Suppose DNS says:

shop.cresignsys.com
 ↓
203.0.113.25

That only means:

Send traffic toward this IP.

It does not tell Nginx which website to serve.

---

55. Nginx Has Its Own Configuration

For example:

server {
    server_name shop.cresignsys.com;

    root /storage/websites/shop.cresignsys.com/public;
}

Now the two systems connect:

DNS
 ↓
203.0.113.25

Nginx
 ↓
shop.cresignsys.com
 ↓
/storage/websites/shop.cresignsys.com/public

---

56. DNS + Nginx

Both must be correct.

DNS

shop.cresignsys.com
        ↓
correct IP

Nginx

shop.cresignsys.com
        ↓
correct document root

If either is wrong, the website can fail.

---

57. Same IP, Multiple Websites

This is one of the most important hosting concepts.

Suppose:

siteA.com
siteB.com
siteC.com

all point to:

203.0.113.25

How does Nginx know which website to serve?

The HTTP request contains the hostname.

---

58. HTTP Host Header

A request may contain:

GET /
Host: siteB.com

Nginx sees:

Host = siteB.com

and selects the corresponding server configuration.

---

59. HTTPS SNI

HTTPS adds another important mechanism:

SNI

Server Name Indication.

During TLS setup, the client indicates the hostname it wants.

This allows one IP address to serve certificates for many domains.

Conceptually:

203.0.113.25:443
        │
        ├── siteA.com
        ├── siteB.com
        └── siteC.com

---

60. One IP, Many Domains

This is the foundation of:

Virtual Hosting

Example:

siteA.com
     ↓
203.0.113.25

siteB.com
     ↓
203.0.113.25

siteC.com
     ↓
203.0.113.25

Nginx separates them using hostname information.

---

61. This Is Exactly What Your Hosting Platform Does

Your CresignSys Hosting Platform can create:

Domain
 ↓
DNS configuration
 ↓
Nginx server block
 ↓
Document root
 ↓
PHP-FPM pool
 ↓
Database

That is the basic architecture of automated hosting.

---

62. www Problem

Suppose:

cresignsys.com

works.

But:

www.cresignsys.com

doesn’t.

Possible reason:

root domain DNS configured
www DNS missing

For example:

cresignsys.com
A
203.0.113.25

but:

www.cresignsys.com

has no A/CNAME record.

---

63. Another www Problem

DNS may be correct:

www
 ↓
203.0.113.25

but Nginx may only have:

server_name cresignsys.com;

instead of:

server_name cresignsys.com www.cresignsys.com;

Then Nginx configuration can still cause unexpected behavior.

---

64. DNS and SSL Are Different

Suppose:

DNS ✓

but:

SSL certificate ✗

The domain can resolve correctly while HTTPS still produces certificate errors.

---

65. DNS and WordPress Are Different

Suppose:

DNS ✓
Nginx ✓
SSL ✓

but:

WordPress

has:

home = wrong URL
siteurl = wrong URL

The site can still behave incorrectly.

---

66. DNS Is Only One Layer

Memorize:

DNS
≠
Website

DNS only answers:

Where should traffic go?

Nginx answers:

Which website should this request receive?

PHP answers:

How should the dynamic request be processed?

WordPress answers:

What content should be generated?

MySQL answers:

What stored data is needed?

---

67. DNS Troubleshooting Workflow

When a new domain doesn’t work:

Step 1

dig +short domain.com

Check the IP.

Step 2

dig A domain.com

Check the A record.

Step 3

dig AAAA domain.com

Check for unexpected IPv6.

Step 4

dig NS domain.com

Find authoritative nameservers.

Step 5

Check Nginx:

sudo nginx -t

Step 6

Check listener:

sudo ss -ltnp | grep ':443'

---

68. nginx -t

This is extremely important.

Run:

sudo nginx -t

It checks the Nginx configuration syntax.

You want something like:

syntax is ok
test is successful

before reloading Nginx.

---

69. Reload Nginx

After a valid configuration change:

sudo systemctl reload nginx

Reload is generally preferable to a full restart for configuration changes because it allows existing connections to be handled more gracefully.

---

70. DNS + Nginx + SSL

A new website generally needs:

1. DNS
   ↓
2. Nginx
   ↓
3. Port 80/443
   ↓
4. SSL certificate
   ↓
5. PHP-FPM
   ↓
6. WordPress

If any layer is missing, the site may not work.

---

71. Why Let’s Encrypt Needs DNS/HTTP Reachability

When obtaining a certificate, the certificate authority must verify control of the domain using an ACME challenge.

Common challenge methods include:

HTTP-01
DNS-01
TLS-ALPN-01

The exact method depends on your setup.

---

72. HTTP-01

For HTTP-01, a challenge is served through HTTP.

Conceptually:

Certificate Authority
        ↓
http://domain/.well-known/acme-challenge/...
        ↓
your server

Therefore port 80 and the domain’s DNS/reachability can matter.

---

73. DNS-01

DNS-01 proves control through a special TXT record.

Conceptually:

Certificate Authority
        ↓
DNS
        ↓
TXT challenge

This can be useful when HTTP exposure isn’t suitable.

---

74. Why DNS Knowledge Helps SSL

If:

DNS

is wrong, certificate issuance may fail.

Therefore:

 ↓
SSL

are connected.

---

75. DNS Propagation

The phrase:

DNS propagation

is often used loosely.

Technically, changes become visible through a combination of:

authoritative DNS updates
+
resolver caching
+
TTL expiration

It’s not simply a single global switch that takes exactly a certain number of hours.

---

76. Check Multiple Resolvers

You can compare:

dig @8.8.8.8 +short learn.cresignsys.com

and:

dig @1.1.1.1 +short learn.cresignsys.com

If they differ, caching or delegation issues may be involved.

---

77. Check Authoritative DNS

First:

dig NS cresignsys.com

Then:

dig @authoritative-server +short learn.cresignsys.com

Now you can determine whether the authoritative server itself has the expected record.

---

78. The Most Important DNS Commands

Memorize:

dig +short domain.com

dig A domain.com

dig AAAA domain.com

dig CNAME www.domain.com

dig NS domain.com

dig MX domain.com

dig +trace domain.com

---

79. Your Domain Hosting Mental Model

For:

learn.cresignsys.com

think:

                    DOMAIN
                       │
                       ▼
                      DNS
                       │
                  A / AAAA
                       │
                       ▼
                  PUBLIC IP
                       │
                       ▼
                OCI NETWORK
                       │
                       ▼
                     VNIC
                       │
                       ▼
                    UBUNTU
                       │
                       ▼
                  TCP :443
                       │
                       ▼
                    NGINX
                       │
                 server_name
                       │
                       ▼
        /storage/websites/learn.../public
                       │
                       ▼
                   PHP-FPM
                       │
                       ▼
                  WORDPRESS
                       │
                       ▼
                    MYSQL

---

80. Lesson 057 — Core Principle

The most important idea:

DNS does not deliver the website. DNS tells the client where to find the network endpoint for the hostname.

Then the rest of the stack takes over:

DNS
 ↓
IP
 ↓
Routing
 ↓
Port
 ↓
Nginx
 ↓
TLS
 ↓
PHP
 ↓
WordPress
 ↓
MySQL

Once you understand this, a domain name stops being mysterious. It becomes the first lookup in a long, measurable chain.

---

Next Lesson — 058

HTTP Deep Dive — What Actually Happens After DNS

We will now go deeper into the protocol that carries your WordPress website:

HTTP
 ↓
Request
 ↓
Response
 ↓
Headers
 ↓
Status codes
 ↓
Methods
 ↓
GET
 ↓
POST
 ↓
Cookies
 ↓
Sessions
 ↓
Cache-Control
 ↓
Compression
 ↓
HTTP/1.1
 ↓
HTTP/2
 ↓
HTTP/3

Then we will follow an actual WordPress request:

GET /about/
        ↓
Nginx
        ↓
PHP-FPM
        ↓
WordPress
        ↓
MySQL
        ↓
HTML
        ↓
Browser

and explain exactly what each layer does.

IP Addressing, Subnets, Gateway, NAT & Routing

This lesson goes one level deeper into networking.

We already know:

Browser
 ↓
DNS
 ↓
Public IP
 ↓
Internet
 ↓
VPS
 ↓
Port 443
 ↓
Nginx

Now we need to understand:

How does the packet know where to go?

---

1. IP Address = Address

Think of an IP address like an address used for network delivery.

Example:

192.168.1.20

But an IP address has two conceptual parts:

Network portion
+
Host portion

---

2. Example

Consider:

192.168.1.20/24

The /24 tells us that the first 24 bits are the network prefix.

Conceptually:

192.168.1 | 20
 network  | host

---

3. Why Do We Need a Network Portion?

Suppose a computer wants to communicate with:

192.168.1.30

and its own address is:

192.168.1.20/24

They belong to the same /24 network.

The computer can communicate with the destination through the local network rather than sending the traffic to its default gateway.

---

4. Different Network

Now suppose the destination is:

10.0.0.20

The source:

192.168.1.20/24

and destination:

10.0.0.20

are on different networks.

The computer needs a router.

Usually that means:

Computer
 ↓
Default Gateway
 ↓
Router
 ↓
Destination network

---

5. Subnet

A subnet is a defined IP network.

Example:

192.168.1.0/24

This represents the network.

Hosts can use addresses within the usable host range, depending on the addressing model.

---

6. /24 in Binary

IPv4 has:

32 bits

A /24 means:

11111111.11111111.11111111.00000000

The first:

24 bits

are the network prefix.

The remaining:

8 bits

are host bits.

---

7. Why 256 Addresses?

With 8 host bits:

2⁸ = 256

possible bit combinations exist.

So:

192.168.1.0/24

contains:

256 IPv4 addresses

Some addresses have special roles in traditional IPv4 subnetting, so the number of ordinary assignable host addresses is lower.

---

8. Network Address

For:

192.168.1.0/24

the network address is:

192.168.1.0

It identifies the subnet itself.

---

9. Broadcast Address

Traditionally, the /24 broadcast address is:

192.168.1.255

It is used for IPv4 broadcast within that subnet.

Cloud networking environments can impose their own rules around which addresses are usable.

---

10. Host Addresses

The traditional usable host range for:

192.168.1.0/24

is:

192.168.1.1
–
192.168.1.254

Again:

network address

and:

broadcast address

are not ordinary host assignments.

---

11. CIDR

CIDR means:

Classless Inter-Domain Routing

Instead of only using old fixed classes such as:

Class A
Class B
Class C

CIDR allows flexible prefix lengths.

Examples:

/8
/16
/24
/25
/26
/27

and many others.

---

12. Smaller Prefix = Larger Network

Compare:

10.0.0.0/24

with:

10.0.0.0/16

A /16 has more host bits:

32 - 16 = 16 host bits

Therefore:

2^16 = 65,536

addresses.

---

13. /24

32 - 24 = 8

host bits.

Therefore:

2^8 = 256

addresses.

---

14. /25

32 - 25 = 7

host bits.

Therefore:

2^7 = 128

addresses.

---

15. /26

32 - 26 = 6

host bits.

Therefore:

2^6 = 64

addresses.

---

16. Subnetting

Suppose you have:

10.0.0.0/24

You can divide it into smaller networks.

For example:

10.0.0.0/26
10.0.0.64/26
10.0.0.128/26
10.0.0.192/26

Each /26 contains:

64 addresses

---

17. Why Subnet?

Cloud networks use subnets to organize systems.

For example:

VCN
│
├── Public subnet
│     └── Web server
│
└── Private subnet
      └── Database

This creates logical network separation.

---

18. Your Oracle Cloud Example

Conceptually:

Oracle Cloud
      │
      ▼
VCN
      │
      ▼
Subnet
      │
      ▼
VNIC
      │
      ▼
Ubuntu VM

The subnet determines the VM’s private IP network.

---

19. Private IP

Your VM may have a private IP such as:

10.0.0.10

This address is used inside the VCN.

It is not normally directly reachable from the public Internet.

---

20. Public IP

Your VM can also have a public IP.

For example:

203.0.113.25

The public Internet uses that address to reach your Internet-facing endpoint when the cloud networking configuration permits it.

---

21. Public-to-Private Mapping

Conceptually:

Internet
     │
     ▼
Public IP
     │
     ▼
Cloud networking
     │
     ▼
Private IP
     │
     ▼
VNIC
     │
     ▼
VM

The exact implementation is controlled by the cloud platform.

---

22. NAT

NAT means:

Network Address Translation

It changes network addressing information as traffic crosses a boundary.

A common concept:

Private IP
     ↓
NAT
     ↓
Public IP

---

23. Why Private IPs Exist

Private address ranges are designed for internal networks.

Common IPv4 private ranges include:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

These are not globally routable Internet addresses.

---

24. Home Network Example

Your home network may look like:

Laptop
192.168.1.20
     │
     ▼
Wi-Fi Router
192.168.1.1
     │
     ▼
Public Internet

The router performs NAT for outbound traffic in the common home-network setup.

---

25. Hosting Example

Your cloud VM can have:

Private IP
10.x.x.x

and a public Internet-facing address.

The cloud networking infrastructure handles the relationship between the public endpoint and the VNIC/private address according to its configuration.

---

26. Routing

Now we reach:

Routing

Routing answers:

Where should this packet go next?

Linux has a routing table.

Run:

ip route

---

27. Example Routing Table

You might see:

10.0.0.0/24 dev ens3
default via 10.0.0.1 dev ens3

Interpretation:

10.0.0.0/24
 ↓
directly reachable through ens3

and:

everything else
 ↓
10.0.0.1

---

28. Default Gateway

The:

10.0.0.1

in this example is the:

Default Gateway

Traffic for destinations that don’t match a more specific route goes there.

---

29. Routing Decision

Suppose the server wants to reach:

10.0.0.50

and has:

10.0.0.0/24

The route matches.

Therefore:

server
 ↓
ens3
 ↓
local network

---

30. Another Destination

Suppose the server wants:

8.8.8.8

That doesn’t belong to:

10.0.0.0/24

So:

server
 ↓
default route
 ↓
gateway
 ↓
Internet

---

31. Longest Prefix Match

When multiple routes match, the router generally chooses the:

Most specific route

Example:

10.0.0.0/8

and:

10.1.0.0/16

Destination:

10.1.5.20

The /16 is more specific than /8.

Therefore it wins.

---

32. Why This Matters

Routing can become complicated when your server has:

multiple interfaces
multiple subnets
VPN
private networks
public networks

But the basic principle remains:

destination
 ↓
routing table
 ↓
best matching route
 ↓
next hop/interface

---

33. ARP

Now we go one level deeper.

On an IPv4 Ethernet-style network, a machine needs to discover the hardware-layer address associated with a local IP.

That mechanism is:

ARP

Address Resolution Protocol.

---

34. IP vs MAC

An IP address is a network-layer address.

A MAC address identifies a network interface at the link layer.

Example:

IP:
192.168.1.20

and:

MAC:
aa:bb:cc:dd:ee:ff

---

35. ARP Question

Suppose:

Computer A
192.168.1.20

needs to send to:

192.168.1.30

It may need to discover:

Which MAC address owns 192.168.1.30?

ARP performs this mapping.

---

36. ARP Cache

Linux keeps recently learned mappings.

Check:

ip neigh

You may see:

192.168.1.1 dev ens3 lladdr aa:bb:cc:dd:ee:ff REACHABLE

---

37. Important Cloud Difference

In cloud networks, you should not assume everything works exactly like a physical Ethernet LAN.

The cloud provider virtualizes and controls the underlying networking.

So:

ARP concepts

remain useful for understanding networking, but the cloud platform may implement virtual networking behavior differently from a traditional physical LAN.

---

38. Packet Journey to Your VPS

Let’s imagine a user opens:

https://learn.cresignsys.com

---

39. Step 1 — DNS

Browser needs the IP address.

learn.cresignsys.com
        ↓
DNS
        ↓
Public IP

---

40. Step 2 — TCP

Browser connects to:

Public-IP:443

using TCP.

---

41. Step 3 — Internet Routing

The packet travels through multiple networks:

User
 ↓
ISP
 ↓
Internet routers
 ↓
Oracle Cloud

You don’t normally control the intermediate Internet routers.

---

42. Step 4 — OCI Network

Inside OCI:

Internet
 ↓
Internet Gateway / appropriate path
 ↓
VCN
 ↓
Subnet
 ↓
VNIC

The exact route depends on your OCI configuration.

---

43. Step 5 — Security

Security rules determine whether the connection is permitted.

Conceptually:

TCP
443
 ↓
OCI security rules
 ↓
ALLOW?

If not:

connection blocked

---

44. Step 6 — Ubuntu

If the packet reaches the VM:

VNIC
 ↓
Linux network interface

Linux then processes the packet.

---

45. Step 7 — TCP Port 443

Linux checks whether a process is listening on:

TCP 443

If Nginx is listening:

TCP
 ↓
Nginx

---

46. Step 8 — TLS

Nginx performs the TLS handshake.

It presents the appropriate certificate.

Then:

encrypted HTTPS connection

is established.

---

47. Step 9 — HTTP

The browser sends an HTTP request such as:

GET /
Host: learn.cresignsys.com

Nginx uses:

Host

to select the appropriate virtual server configuration.

---

48. Step 10 — Website

Nginx maps the request to:

/storage/websites/learn.cresignsys.com/public

Then:

static file

may be served directly.

Or:

PHP request
 ↓
PHP-FPM
 ↓
WordPress

---

49. Step 11 — Database

WordPress may request:

MySQL

The database responds.

Then:

PHP
 ↓
Nginx
 ↓
TLS
 ↓
Browser

---

50. The Full Journey

Browser
  │
  ▼
DNS
  │
  ▼
Public IP
  │
  ▼
Internet routers
  │
  ▼
OCI Internet connectivity
  │
  ▼
VCN
  │
  ▼
Subnet
  │
  ▼
VNIC
  │
  ▼
Linux interface
  │
  ▼
TCP 443
  │
  ▼
Nginx
  │
  ▼
TLS
  │
  ▼
HTTP
  │
  ▼
PHP-FPM
  │
  ▼
WordPress
  │
  ▼
MySQL

---

51. How to Troubleshoot Each Layer

This is where your learning becomes practical.

DNS

dig +short learn.cresignsys.com

---

Interface

ip addr

---

Route

ip route

---

Port

sudo ss -ltnp | grep ':443'

---

Nginx

sudo systemctl status nginx

---

Firewall

sudo ufw status

---

HTTP

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

---

52. ip route get

One especially useful command is:

ip route get 8.8.8.8

Linux tells you which route it would use to reach that destination.

For example:

8.8.8.8 via 10.0.0.1 dev ens3

Conceptually:

8.8.8.8
 ↓
gateway 10.0.0.1
 ↓
interface ens3

---

53. ip neigh

You can inspect neighbor information:

ip neigh

This is useful when investigating local network connectivity.

---

54. ss

Use:

sudo ss -lntup

You can inspect:

TCP listeners
UDP listeners
ports
processes

---

55. TCP vs UDP

You should now distinguish:

TCP

connection-oriented
reliable
ordered

UDP

connectionless
no built-in delivery guarantee
low protocol overhead

---

56. Why Websites Use TCP

Traditional HTTP/1.1 and HTTP/2 over TLS commonly use:

TCP

HTTP/3 instead uses:

QUIC
 ↓
UDP

This is a more advanced topic.

For your current Nginx/WordPress stack, TCP is the primary concept to understand first.

---

57. Port 443 Doesn’t Mean HTTPS Automatically

This is important.

A port is just a number.

You can configure:

some application
 ↓
TCP 443

But that doesn’t automatically make it HTTPS.

HTTPS requires:

TLS
+
HTTP

---

58. Port 80 Doesn’t Force HTTP Either

Likewise:

port 80

is conventional for HTTP, but software can listen there using other protocols.

The port number is a convention.

---

59. IP + Port

Think of:

IP

as identifying the machine/network endpoint.

And:

Port

as identifying a service endpoint on that host.

Together:

203.0.113.25:443

identify a TCP endpoint.

---

60. Socket Connection

A TCP connection is identified by endpoints.

Conceptually:

Client IP:client-port
        ↕
Server IP:443

For example:

192.168.1.20:51832
        ↕
203.0.113.25:443

The client-side port is usually dynamically selected.

---

61. Ephemeral Ports

Client applications usually use temporary:

Ephemeral ports

For example:

51832

Then:

client
192.168.1.20:51832

connects to:

server
203.0.113.25:443

---

62. Why the Server Can Handle Many Users

The server isn’t limited to one connection on port 443.

A single listening port can have many simultaneous TCP connections.

Conceptually:

              Nginx :443
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
 Client A      Client B    Client C
 :50001        :50002      :50003

Each connection has a distinct client endpoint.

---

63. This Connects to RAM

Now combine networking with your previous lesson.

More simultaneous requests can mean:

more TCP connections
 ↓
more Nginx work
 ↓
more PHP requests
 ↓
more PHP workers
 ↓
more RAM

Therefore:

NETWORK
 ↓
APPLICATION
 ↓
CPU/RAM

are connected.

---

64. Traffic → PHP → MySQL

A busy website can generate:

1000 requests
      ↓
Nginx
      ↓
PHP
      ↓
MySQL

If caching is poor:

database workload increases

Then:

CPU
RAM
storage I/O

can all increase.

---

65. Why Caching Is So Important

With page cache:

Request
 ↓
Nginx/cache
 ↓
HTML

Without it:

Request
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL

Caching can therefore reduce work throughout the stack.

---

66. Your Hosting Architecture Is Becoming Clear

You can now see:

             INTERNET
                 │
                 ▼
                DNS
                 │
                 ▼
             PUBLIC IP
                 │
                 ▼
              OCI VCN
                 │
                 ▼
              SUBNET
                 │
                 ▼
               VNIC
                 │
                 ▼
               UBUNTU
                 │
          ┌──────┴──────┐
          ▼             ▼
        NETWORK        STORAGE
          │             │
          ▼             ▼
        NGINX       /storage
          │             │
          ▼             ▼
      PHP-FPM       WordPress
          │
          ▼
       MySQL

And security surrounds it:

Cloud security
+
Linux firewall
+
Users
+
Groups
+
Permissions

---

67. Lesson 056 — Core Principle

The most important idea:

Routing determines where traffic goes; ports determine which service receives it.

For your WordPress server:

learn.cresignsys.com
        ↓
DNS
        ↓
Public IP
        ↓
OCI routing
        ↓
VNIC
        ↓
TCP 443
        ↓
Nginx
        ↓
PHP-FPM
        ↓
WordPress

If you understand that chain, you can troubleshoot most basic hosting connectivity problems systematically.

---

Next Lesson — 057

DNS Deep Dive — How learn.cresignsys.com Finds Your VPS

We will go deeper into:

Domain
 ↓
DNS hierarchy
 ↓
Root DNS
 ↓
TLD
 ↓
Authoritative nameserver
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
TTL
 ↓
DNS cache
 ↓
Recursive resolver
 ↓
Your VPS

Then we will connect it directly to your CresignSys domains and explain why:

domain works
domain doesn't work
www works
root domain doesn't work
IPv4 works
IPv6 doesn't work

can all happen even when the WordPress installation itself is perfectly correct.

Linux Networking — From Internet to Nginx

We now move from storage and permissions into the networking layer.

The goal is to understand exactly what happens when someone opens:

https://learn.cresignsys.com

---

1. The Complete Journey

At a high level:

Browser
   ↓
DNS
   ↓
Public IP
   ↓
Internet
   ↓
Oracle Cloud network
   ↓
VNIC
   ↓
Ubuntu network interface
   ↓
TCP port 443
   ↓
Nginx
   ↓
HTTPS
   ↓
Website

Each layer can fail independently.

---

2. What Is a Network?

A network allows computers to exchange data.

For example:

Your computer
      │
      │ Internet
      │
      ▼
Oracle VPS

Data travels between the two systems.

---

3. IP Address

An IP address identifies a network endpoint.

IPv4 example:

203.0.113.25

IPv6 example:

2001:db8::25

Your VPS has network addresses assigned to its interfaces.

---

4. Private vs Public IP

A server can have:

Private IP

and:

Public IP

The private address is used inside a private network.

The public address is reachable through the Internet, subject to routing and security controls.

---

5. Example

Conceptually:

Internet
   │
   ▼
Public IP
203.0.113.25
   │
   ▼
Private IP
10.x.x.x
   │
   ▼
Ubuntu

The exact addressing depends on your Oracle Cloud network configuration.

---

6. Your VNIC

In Oracle Cloud, your VM uses a:

VNIC

Virtual Network Interface Card.

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

Conceptually:

Internet
   ↓
OCI Network
   ↓
VNIC
   ↓
Ubuntu

---

7. Physical NIC vs VNIC

A physical computer may have:

Ethernet card

A cloud VM generally sees a virtual network interface:

VNIC

The cloud provider manages the underlying physical networking.

---

8. Linux Sees a Network Interface

Inside Ubuntu, you can inspect interfaces with:

ip addr

or:

ip a

You may see something similar to:

lo
ens3

The exact interface name can differ.

---

9. Loopback

One interface you will usually see is:

lo

This is:

Loopback

It represents the computer talking to itself.

Common address:

127.0.0.1

---

10. Why 127.0.0.1 Matters

Suppose Nginx listens on:

127.0.0.1:8080

That means it is accessible through the local machine’s loopback interface.

It does not necessarily mean it is directly reachable from the Internet.

---

11. 0.0.0.0

You may also see a service listening on:

0.0.0.0:80

This means it is listening on IPv4 interfaces generally, subject to other networking controls.

For example:

0.0.0.0:80

can allow connections arriving through the server’s network interfaces.

---

12. IPv6 Equivalent

For IPv6, you may see:

[::]:80

This represents listening on IPv6 addresses broadly, subject to configuration.

---

13. Check Interfaces

Run:

ip addr

Look for:

inet

and:

inet6

Example:

inet 10.0.0.10/24

---

14. CIDR

The:

/24

is part of:

CIDR notation

CIDR describes the network prefix length.

Example:

10.0.0.10/24

means:

IP = 10.0.0.10
prefix length = 24 bits

---

15. IPv4 Structure

IPv4 has:

32 bits

Example:

192.168.1.10

It contains four octets:

192
.
168
.
1
.
10

Each octet is 8 bits.

---

16. /24

A /24 means:

24 bits = network portion
8 bits  = host portion

Conceptually:

192.168.1 | .10
network   | host

---

17. Don’t Memorize Subnet Math Yet

For now remember:

IP address
+
prefix length
=
network addressing information

We will study subnetting separately.

---

18. Default Gateway

Your server needs to know where to send traffic that isn’t on its local network.

That is the job of the:

Default Gateway

Check:

ip route

You may see:

default via 10.0.0.1 dev ens3

Conceptually:

Ubuntu
 ↓
default gateway
 ↓
outside network

---

19. Routing Table

Linux maintains a:

Routing Table

It decides where packets should go.

Check it:

ip route

Example:

10.0.0.0/24 dev ens3
default via 10.0.0.1 dev ens3

---

20. What Does default Mean?

It means:

If no more specific route matches the destination, use this route.

Conceptually:

Destination known locally?
       │
   yes │ no
       ▼
 local route
       │
       └──── no ────► default route

---

21. Packet

When your browser sends data, it is broken into network packets.

Conceptually:

Message
 ↓
Network data
 ↓
Packets
 ↓
Internet

Each packet contains addressing information needed for delivery.

---

22. IP Layer

The IP protocol handles addressing and routing between networks.

Conceptually:

Source IP
     ↓
Packet
     ↓
Destination IP

---

23. TCP

For a typical HTTPS connection, TCP is involved.

TCP provides a reliable, ordered byte stream.

The simplified hierarchy is:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Network interface

---

24. Port

An IP address identifies a network endpoint.

A:

Port

helps identify the service/application endpoint on that host.

For example:

203.0.113.25:443

means:

IP   = 203.0.113.25
Port = 443

---

25. Common Ports

You should know:

22   SSH
80   HTTP
443  HTTPS
25   SMTP
53   DNS
3306 MySQL

These are conventional defaults, not laws.

Services can be configured to use other ports.

---

26. Why Ports Exist

Imagine your VPS has:

Nginx
SSH
MySQL

all running on the same server.

They need different network endpoints.

Conceptually:

VPS
│
├── :22   SSH
├── :80   HTTP
├── :443  HTTPS
└── :3306 MySQL

---

27. Socket

A network connection is associated with a:

Socket

A simplified endpoint can be thought of as:

IP + protocol + port

For example:

TCP
203.0.113.25
443

---

28. Listening Socket

When Nginx waits for connections:

Nginx
 ↓
listen
 ↓
TCP :443

It is listening on a socket.

Check:

sudo ss -ltnp

---

29. Understand ss

Example:

LISTEN
0
128
0.0.0.0:443

The important part:

0.0.0.0:443

means something is listening on TCP port 443 on IPv4 interfaces generally.

---

30. Find Port 80

sudo ss -ltnp | grep ':80'

Find HTTPS:

sudo ss -ltnp | grep ':443'

---

31. Example

Suppose you see:

LISTEN 0 511 0.0.0.0:443

This suggests:

something
 ↓
listening
 ↓
TCP
 ↓
port 443

Now identify the process using the -p information.

---

32. Nginx

If the process is:

nginx

then:

Nginx
 ↓
TCP 443

is listening.

That is a good sign.

But it doesn’t prove Internet connectivity yet.

---

33. Local vs External Testing

Suppose:

curl https://localhost

works.

But:

curl https://your-domain.com

fails.

That means the problem may be somewhere between:

Internet
 ↓
DNS
 ↓
cloud network
 ↓
firewall
 ↓
server

---

34. Local Test

Run:

curl -I http://127.0.0.1

This tests locally.

If Nginx is listening on port 80, you may receive an HTTP response.

---

35. HTTPS Local Test

You might use:

curl -kI https://127.0.0.1

The -k option tells curl not to reject an invalid/untrusted certificate during this test.

This is a diagnostic technique, not a recommendation to ignore certificate validation in normal use.

---

36. Test the Domain

From a client:

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

This tests much more of the actual path.

---

37. DNS Check

Before network troubleshooting:

dig +short learn.cresignsys.com

You want to confirm it resolves to the expected public IP.

---

38. DNS Correct but Website Fails

Suppose:

DNS
✓

but:

Website
✗

Then investigate:

port
firewall
Nginx
TLS
application

---

39. Connection Refused

Suppose:

Connection refused

This often means the destination was reachable at the network level, but no service accepted the connection on that endpoint, or an active firewall/reject rule rejected it.

Common causes include:

Nginx not running
nothing listening on the port
wrong bind address
firewall reject

---

40. Connection Timed Out

A timeout often indicates that packets or responses aren’t getting through as expected.

Possible causes include:

cloud security rules
firewall
routing
wrong IP
service unreachable
network path issue

The exact cause must be tested.

---

41. Refused vs Timeout

A useful first approximation:

refused
=
you reached something, but connection wasn't accepted

timeout
=
you didn't receive the expected response in time

These are clues, not definitive diagnoses.

---

42. Oracle Cloud Security

Your Oracle Cloud environment has network security controls.

For a web server, you normally need appropriate inbound access for:

TCP 80
TCP 443

For SSH:

TCP 22

But exposure should be limited to what is actually required.

---

43. Cloud Firewall vs Linux Firewall

There can be multiple security layers.

For example:

Internet
 ↓
OCI network security
 ↓
Ubuntu firewall
 ↓
Nginx

A connection can be blocked before it ever reaches Nginx.

---

44. OCI Network Layer

At the Oracle Cloud level, your VM can be associated with:

VCN
Subnet
VNIC
Route Table
Security List
Network Security Group
Public IP

These components work together to determine network reachability.

---

45. VCN

VCN means:

Virtual Cloud Network

Think of it as your virtual private network environment in Oracle Cloud.

Conceptually:

OCI
 ↓
VCN
 ↓
Subnet
 ↓
VNIC
 ↓
VM

---

46. Subnet

A subnet is a logical IP network within the VCN.

For example:

VCN
│
├── Public subnet
│
└── Private subnet

The exact design depends on your architecture.

---

47. Public Subnet

A public subnet can be configured so that resources can have paths to/from the Internet through appropriate routing and public IP configuration.

It does not mean:

Every resource is automatically exposed to every Internet connection.

Security rules still matter.

---

48. Private Subnet

A private subnet is typically designed without direct public Internet exposure for its resources.

For example:

Internet
   │
   ▼
Web server
   │
   ▼
Private database

This is a common architecture.

---

49. Public IP

A public IP provides an Internet-facing address for the VM/network interface when appropriately configured.

Your domain’s A record can point to it.

Conceptually:

learn.cresignsys.com
        ↓
public IP
        ↓
VPS

---

50. Private IP

Inside the VCN, the VNIC has a private IP.

For example:

10.0.0.10

The Internet does not normally directly route to this RFC1918 private address.

---

51. NAT

NAT means:

Network Address Translation

It allows traffic to be translated between addressing domains.

For example, private systems may access the Internet through a NAT gateway without receiving public IP addresses.

This becomes important in more advanced cloud architectures.

---

52. Internet Gateway

A VCN can use an:

Internet Gateway

to provide Internet connectivity for appropriately routed resources.

Conceptually:

VM
 ↓
VCN
 ↓
Internet Gateway
 ↓
Internet

Routing and security rules must also permit the traffic.

---

53. Route Table

A route table tells the VCN where traffic should go.

Conceptually:

Destination
0.0.0.0/0
       ↓
Internet Gateway

means traffic destined for addresses outside the local network can be routed toward the Internet gateway, assuming the rest of the configuration permits it.

---

54. Security List

Oracle Cloud can use security lists associated with subnets.

They define allowed traffic rules.

For a web server you might allow:

TCP 80
TCP 443

and SSH:

TCP 22

from an appropriate source range.

---

55. Network Security Group

OCI also supports:

NSG

Network Security Group.

NSGs allow security rules to be associated with VNICs/resources rather than simply treating the whole subnet as one security boundary.

This can provide more granular architecture.

---

56. Security Rule Concept

Think:

Source
 ↓
Protocol
 ↓
Destination port
 ↓
Allow / deny

Example concept:

Internet
 ↓
TCP
 ↓
443
 ↓
ALLOW
 ↓
web server

---

57. Don’t Open Everything

Avoid:

0.0.0.0/0

for every possible port.

For example, exposing MySQL:

3306

to the entire Internet is generally unnecessary for a typical single-server WordPress setup.

---

58. MySQL Should Usually Be Private

If:

Nginx
PHP-FPM
MySQL

are all on the same VPS, WordPress can communicate with MySQL locally.

There is usually no reason to expose:

3306

to the Internet.

---

59. SSH

SSH uses:

TCP 22

by default.

If you expose SSH publicly:

Internet
 ↓
TCP 22
 ↓
SSH

you should secure it appropriately.

---

60. Web Ports

For normal websites:

HTTP
TCP 80

and:

HTTPS
TCP 443

are the common public ports.

---

61. HTTP Redirect

Many websites use:

Port 80
 ↓
redirect
 ↓
HTTPS 443

So both ports can be needed.

---

62. HTTPS Flow

When the user enters:

https://learn.cresignsys.com

the simplified path is:

DNS
 ↓
Public IP
 ↓
TCP 443
 ↓
TLS handshake
 ↓
HTTP request
 ↓
Nginx

---

63. TCP Three-Way Handshake

TCP connection establishment traditionally begins with:

Client → SYN
Server → SYN-ACK
Client → ACK

Conceptually:

Client                    Server

  SYN  -------------------->

       <-------------------- SYN-ACK

  ACK  -------------------->

Now the TCP connection is established.

---

64. Why TCP Handshake Matters

If you cannot establish TCP:

TLS

cannot proceed normally.

Therefore:

TCP failure
 ↓
HTTPS failure

---

65. TLS Comes After TCP

The simplified order:

DNS
 ↓
IP routing
 ↓
TCP connection
 ↓
TLS handshake
 ↓
HTTP

This is important for troubleshooting.

---

66. Test TCP Port

From another machine, you can use:

nc -vz example.com 443

or:

nc -vz example.com 80

If nc is installed.

---

67. What Does nc -vz Do?

It attempts to connect to the specified host and port.

Example:

example.com:443

This helps answer:

Can I establish a TCP connection to port 443?

---

68. curl Tests More

Compare:

nc -vz example.com 443

with:

curl -I https://example.com

nc focuses on connectivity.

curl can test higher-level HTTP/HTTPS behavior.

---

69. ping

You may also know:

ping example.com

But:

Ping is not a reliable test of whether a website works.

Why?

Because ping uses:

ICMP

while websites use:

TCP 80/443

---

70. Ping Can Fail While Website Works

A server may block ICMP.

So:

ping
✗

doesn’t necessarily mean:

website
✗

---

71. Website Can Fail While Ping Works

Conversely:

ping
✓

only tells you that ICMP communication worked.

It doesn’t prove:

TCP 443
✓

---

72. Better Website Test

Use:

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

This tests the actual HTTP/HTTPS service.

---

73. Check Nginx

On the VPS:

sudo systemctl status nginx

Then:

sudo ss -ltnp | grep ':443'

You want to establish:

Nginx
✓ running

Port 443
✓ listening

---

74. Check Firewall

On Ubuntu, you may use:

sudo ufw status

If UFW is active, check whether the required ports are allowed.

For example, you may see rules for:

80/tcp
443/tcp

---

75. Important: UFW May Not Be Your Only Firewall

Even if:

ufw

looks correct, Oracle Cloud network security may still block traffic.

Therefore:

OCI security
+
Ubuntu firewall
+
service listener

all need to align.

---

76. Complete Port 443 Troubleshooting

If HTTPS doesn’t work:

1. DNS
   ↓
2. Public IP
   ↓
3. OCI routing
   ↓
4. OCI security rules
   ↓
5. Ubuntu firewall
   ↓
6. Nginx listening
   ↓
7. TCP 443
   ↓
8. TLS certificate
   ↓
9. Nginx server_name
   ↓
10. WordPress

---

77. Example Failure

DNS

learn.cresignsys.com
 ↓
correct IP

Nginx

running

Port

443
not listening

Result:

HTTPS fails

The problem is not DNS.

---

78. Another Failure

Everything:

DNS ✓
Nginx ✓
443 ✓

but OCI security rules:

443 blocked

Result:

Internet
 ↓
blocked
 ↓
Nginx never receives connection

---

79. Another Failure

Everything:

DNS ✓
443 ✓
Nginx ✓
TLS ✓

but:

server_name

is wrong.

You may receive the wrong website or default server.

---

80. Another Failure

Everything reaches Nginx:

DNS ✓
network ✓
TCP ✓
TLS ✓
Nginx ✓

but PHP-FPM is down.

Then a dynamic WordPress request may produce:

502 Bad Gateway

Now you move to the application layer.

---

81. This Is the Layered Troubleshooting Method

Never randomly change everything.

Move from outside to inside:

DNS
 ↓
IP
 ↓
route
 ↓
cloud firewall
 ↓
Linux firewall
 ↓
TCP
 ↓
Nginx
 ↓
TLS
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

---

82. Essential Networking Commands

Interfaces

ip addr

Routes

ip route

Listening ports

sudo ss -ltnp

DNS

dig +short example.com

HTTP/HTTPS

curl -I https://example.com

TCP test

nc -vz example.com 443

Firewall

sudo ufw status

---

83. Three Commands to Memorize First

If you remember only three:

ip addr

ip route

sudo ss -ltnp

They tell you:

What interfaces do I have?
        ↓
Where does traffic go?
        ↓
What services are listening?

---

84. Your Oracle VPS Mental Model

Think of your VPS as:

                  INTERNET
                      │
                      ▼
                PUBLIC IP
                      │
                      ▼
                     VCN
                      │
                      ▼
                   SUBNET
                      │
                      ▼
                    VNIC
                      │
                      ▼
                UBUNTU NETWORK
                      │
             ┌────────┴────────┐
             ▼                 ▼
          TCP 80            TCP 443
             │                 │
             ▼                 ▼
          NGINX              NGINX
                               │
                               ▼
                              TLS
                               │
                               ▼
                           WORDPRESS

---

85. The Deepest Concept

A domain name is not directly connected to WordPress.

The actual chain is:

Domain
 ↓
DNS
 ↓
IP
 ↓
Network routing
 ↓
VNIC
 ↓
Linux interface
 ↓
TCP port
 ↓
Listening socket
 ↓
Nginx process
 ↓
Website configuration
 ↓
PHP-FPM
 ↓
WordPress

Each arrow represents another technical layer.

---

86. Lesson 055 Core Principle

Remember:

A server being online does not mean a website is reachable.

For the website to work:

DNS
✓

Routing
✓

Cloud security
✓

Linux firewall
✓

TCP port
✓

Nginx
✓

TLS
✓

PHP-FPM
✓

WordPress
✓

MySQL
✓

All required layers must work together.

---

Next Lesson — 056

Linux Networking Deeper — IP, Subnet, Gateway, NAT & Routing

We will now go below the port level and understand:

IPv4
 ↓
Binary
 ↓
Subnet mask
 ↓
CIDR
 ↓
Network address
 ↓
Broadcast
 ↓
Host address
 ↓
Gateway
 ↓
ARP
 ↓
Routing table
 ↓
NAT
 ↓
Public ↔ Private IP

Then we will apply it directly to your Oracle Cloud VCN, subnet, VNIC and public IP, so you understand exactly how a packet travels from a user’s laptop in Kerala to your VPS.

Linux Users, Groups & Permissions

This lesson is one of the most important for running a real web-hosting server.

You now know:

Domain
 ↓
DNS
 ↓
IP
 ↓
Network
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
Storage

Now we ask:

Who is allowed to do what?

That is the job of:

Users
Groups
Permissions
Ownership

---

1. Linux Is a Multi-User System

Linux was designed so that multiple users and processes can safely share one system.

For example:

root
ubuntu
www-data
mysql

can all exist on the same server.

They do not automatically have the same permissions.

---

2. Why This Matters for Hosting

Your VPS may run:

Nginx
PHP-FPM
MySQL
SSH
WordPress

If every process had unrestricted access to everything:

security disaster

Instead:

Nginx
 ↓
limited permissions

PHP-FPM
 ↓
limited permissions

MySQL
 ↓
limited permissions

This is called:

Least Privilege

Give a process only the access it actually needs.

---

3. Root

The most powerful traditional Linux user is:

root

Root has very broad authority over the system.

You can verify your current user:

whoami

If the result is:

root

you are operating as root.

---

4. Why Root Is Dangerous

Suppose you run:

rm -rf /some-directory

as a normal user.

You may receive:

Permission denied

As root, the command may succeed.

Therefore:

Root removes many of the protection barriers that normally prevent accidental or unauthorized changes.

---

5. sudo

Instead of logging in as root, Ubuntu commonly uses:

sudo

Example:

sudo systemctl restart nginx

This means approximately:

Run this command with elevated privileges according to the user’s sudo permissions.

---

6. Normal User

You might log into your VPS as:

ubuntu

Then:

whoami

returns:

ubuntu

But:

sudo whoami

may return:

root

if the user is authorized for sudo.

---

7. Why This Is Better

Instead of doing everything as root:

login
 ↓
root
 ↓
everything

you can use:

ubuntu
 ↓
normal work
 ↓
sudo
 ↓
administrative command

This reduces accidental damage.

---

8. Linux User Identity

Every user has a:

UID

User ID.

Run:

id

Example:

uid=1000(ubuntu) gid=1000(ubuntu) groups=...

The numbers are what the kernel fundamentally uses to identify users.

---

9. Root UID

Traditionally:

root
UID = 0

UID 0 has special administrative privileges.

---

10. Groups

Linux also uses:

Groups

A group allows multiple users to share permissions.

For example:

webadmins

could contain:

ubuntu
developer1
developer2

Then a file could be accessible to the group.

---

11. GID

Every group has a:

GID

Group ID.

Run:

id

to see your user and group information.

---

12. Example

Suppose:

User:
ubuntu

UID:
1000

Primary group:
ubuntu

GID:
1000

The exact IDs depend on the system.

---

13. id

Use:

id username

Example:

id ubuntu

You can also inspect:

id www-data

---

14. www-data

On Ubuntu/Debian systems, web services commonly use:

www-data

as a service account.

You can check:

id www-data

You may see a UID/GID assigned to it.

---

15. Why Does www-data Exist?

Imagine PHP-FPM runs as:

www-data

If PHP is compromised, you don’t want the attacker to automatically have:

root

access.

Instead, the compromised process initially has the permissions of its service account.

This is a major security boundary.

---

16. MySQL User

MySQL commonly runs under a dedicated account such as:

mysql

Check:

id mysql

This separates MySQL from other services.

---

17. SSH

SSH service processes may begin with elevated privileges for specific system operations and then use lower-privileged contexts for sessions as appropriate.

The important concept is:

SSH service
≠
automatically root shell

Your login account determines the normal user context of your shell.

---

18. File Ownership

Every normal file has:

owner
group
permissions

Run:

ls -l

Example:

-rw-r--r-- 1 www-data www-data index.php

The important parts are:

owner = www-data
group = www-data

---

19. Three Permission Classes

Linux traditionally evaluates permissions for:

Owner
Group
Others

For example:

-rwxr-x---

means:

Owner  → rwx
Group  → r-x
Others → ---

---

20. Read

r

means:

read

For a file:

read contents

For a directory:

list entries

subject to the other permissions needed for directory access.

---

21. Write

w

For a file:

modify contents

For a directory:

create/delete/rename entries

subject to directory access and other controls.

---

22. Execute

x

For a file:

execute

For a directory:

traverse/search

This difference is extremely important.

---

23. Directory x

Suppose:

/storage/websites/site/public/

has:

x

permission.

It means a user/process can traverse that directory if the other required permissions are satisfied.

Without appropriate x permissions on parent directories, a file can remain inaccessible even if the file itself is readable.

---

24. Example

You have:

/storage/websites/site/public/index.php

Even if:

index.php

is:

644

the web server still needs appropriate access to the parent directories.

---

25. Numeric Permissions

Linux commonly represents permissions numerically.

Remember:

r = 4
w = 2
x = 1

Add them.

---

26. 7

4 + 2 + 1 = 7

Therefore:

7 = rwx

---

27. 6

4 + 2 = 6

Therefore:

6 = rw-

---

28. 5

4 + 1 = 5

Therefore:

5 = r-x

---

29. 4

4 = r--

---

30. 0

0 = ---

---

31. 755

Break it into:

7 5 5

Therefore:

Owner  = rwx
Group  = r-x
Others = r-x

---

32. 644

6 4 4

Therefore:

Owner  = rw-
Group  = r--
Others = r--

This is commonly used for regular web files.

---

33. Files vs Directories

A common pattern is:

Files
→ 644

and:

Directories
→ 755

But this is not a universal law.

The correct permissions depend on:

application
owner
group
web server
deployment model
security requirements

---

34. Never Automatically Use 777

You may see:

chmod -R 777 website/

recommended in random tutorials.

Avoid this.

It means:

Owner  = rwx
Group  = rwx
Others = rwx

Everyone gets broad read/write/execute access.

---

35. Why 777 Is Dangerous

Suppose a web-accessible directory has:

777

and an application vulnerability allows arbitrary file creation.

An attacker may potentially write malicious files there.

You have unnecessarily expanded the attack surface.

---

36. chmod

Change permissions with:

chmod

Example:

chmod 644 index.php

---

37. Directory Example

chmod 755 public

Now:

owner → rwx
group → r-x
others → r-x

---

38. Recursive chmod

You can use:

chmod -R

But be extremely careful.

For example:

chmod -R 755 website/

will also make regular files executable.

That is often undesirable.

---

39. Better Recursive Strategy

A common pattern is to set:

directories → 755
files → 644

using find.

For example:

find website/ -type d -exec chmod 755 {} \;

and:

find website/ -type f -exec chmod 644 {} \;

This is still only a baseline; ownership and application requirements matter.

---

40. Ownership

Use:

chown

Example:

sudo chown www-data:www-data index.php

This means:

owner = www-data
group = www-data

---

41. chown user:group

General syntax:

chown USER:GROUP FILE

Example:

sudo chown ubuntu:www-data index.php

Now:

owner = ubuntu
group = www-data

---

42. Why Separate Owner and Group?

This can create a useful hosting model.

For example:

Owner:
deployment user

Group:
www-data

Then:

developer
      ↓
owns files

www-data
      ↓
can access required files

This can be more flexible than making everything owned by www-data.

---

43. Your Hosting Platform

A clean architecture might eventually have:

site owner/deployment user
          │
          ▼
     website files
          │
          ▼
      www-data
          │
          ▼
     PHP-FPM/Nginx

The exact model depends on whether users have shell access, how deployments work, and whether sites are isolated.

---

44. Security Principle

Ask:

Does PHP really need write access to the entire WordPress installation?

Usually:

No.

The web application often needs write access to specific locations such as uploads/cache directories, while core files should ideally be more restricted.

---

45. Why This Matters

If PHP can modify:

wp-config.php
all plugin files
all theme files
all WordPress core files

then a compromised PHP application may be able to persist malicious code throughout the site.

Reducing unnecessary write permissions can improve security.

---

46. WordPress Upload Directory

WordPress commonly needs to write to:

wp-content/uploads/

Therefore this directory may need write access for the PHP process.

But that does not mean:

entire website

should be writable.

---

47. Example Security Model

Conceptually:

WordPress core
 ↓
readable
 ↓
not generally writable by PHP

while:

wp-content/uploads
 ↓
writable by PHP

This is a stronger security posture.

The exact implementation must account for updates, plugins, deployment tools, and operational requirements.

---

48. umask

Now a deeper concept:

umask

It controls which permission bits are removed from newly created files/directories.

Check:

umask

You might see:

0022

---

49. Why umask Matters

Suppose a program requests default permissions when creating a file.

The process’s umask can restrict those permissions.

Conceptually:

Requested permissions
        ↓
      umask
        ↓
Actual permissions

---

50. Example

A common umask:

022

can result in typical defaults such as:

files → 644
directories → 755

depending on what permissions the application requests when creating them.

---

51. setgid on Directories

There is another useful permission feature:

setgid

When applied to a directory, newly created files/directories can inherit the directory’s group rather than simply using the creator’s primary group, subject to system behavior.

This can be useful for shared website administration.

---

52. Example

Suppose:

website/

belongs to:

webteam

Set the directory’s setgid bit:

chmod g+s website/

Then newly created entries can inherit:

webteam

as their group.

---

53. Why Hosting Systems May Use This

Suppose:

developer

and:

www-data

both need controlled access.

A shared group can simplify collaboration.

Example:

webteam
├── developer
└── www-data

Then:

website files
 ↓
group = webteam

---

54. Sticky Bit

Another special permission is:

sticky bit

It is commonly seen on:

/tmp

Check:

ls -ld /tmp

You may see something like:

drwxrwxrwt

The final:

t

represents the sticky bit.

---

55. Why /tmp Uses Sticky Bit

Many users/processes can write to /tmp.

The sticky bit helps prevent one user from arbitrarily deleting another user’s files there, subject to ownership and privileges.

---

56. Special Permissions Summary

You now have:

setuid
setgid
sticky bit

They are advanced permission mechanisms.

For now remember:

setgid directory
=
group inheritance

sticky directory
=
restrict deletion of others' entries

---

57. ACLs

Linux can also support:

Access Control Lists

ACLs provide more granular permissions than the traditional:

owner
group
others

model.

For example:

owner → rwx
group → r-x
developer2 → rwx
others → ---

---

58. getfacl

Check ACLs:

getfacl file.txt

If ACLs are being used, this can explain permissions that aren’t obvious from:

ls -l

---

59. setfacl

ACLs can be modified using:

setfacl

Don’t add ACLs casually; they increase configuration complexity.

But they are useful for advanced shared hosting and deployment scenarios.

---

60. Permission Troubleshooting

Suppose WordPress says:

Unable to create directory

Don’t immediately run:

chmod -R 777

Instead investigate.

---

61. Step 1 — Identify the Process User

Find PHP-FPM:

ps aux | grep php-fpm

Look at which user its worker processes run as.

Often:

www-data

but verify your actual configuration.

---

62. Step 2 — Inspect Directory

ls -ld wp-content/uploads

Example:

drwxr-xr-x www-data www-data uploads

---

63. Step 3 — Check Parent Directories

Inspect:

namei -l /storage/websites/site/public/wp-content/uploads

This is an excellent command for permission troubleshooting.

It shows permissions and ownership along the entire path.

---

64. Why namei Is Powerful

Instead of checking:

/storage
/storage/websites
/storage/websites/site
/storage/websites/site/public
...

one by one:

namei -l PATH

shows the path components together.

---

65. Step 4 — Test as the Service User

For a controlled diagnostic, you can test access as the relevant user.

For example:

sudo -u www-data ls -la /storage/websites/site/public

This asks:

Can www-data access this directory?

---

66. Test File Creation

In a safe temporary/test directory:

sudo -u www-data touch test-file

If it fails:

Permission denied

you have confirmed the service user lacks the required write access there.

Do not create test files in production directories without removing them afterward.

---

67. Ownership Isn’t Everything

Suppose:

owner = www-data

but:

permissions = 444

Then the owner cannot write.

Therefore:

ownership
+
permissions

must be considered together.

---

68. Group Isn’t Enough Either

Suppose:

group = www-data

but:

permissions = 640

The group gets:

r--

not write access.

Therefore:

group membership

and:

group permission bits

both matter.

---

69. Effective Access

When troubleshooting, think:

Who is the process?
        ↓
What UID/GID does it have?
        ↓
Who owns the file?
        ↓
What group owns it?
        ↓
What permission class applies?
        ↓
Can it traverse the path?
        ↓
Can it perform the required operation?

This is much better than randomly changing permissions.

---

70. WordPress Example

Suppose:

PHP-FPM
 ↓
www-data

and:

/storage/websites/site/public/wp-content/uploads

is:

drwxr-xr-x ubuntu ubuntu

Then www-data may not have write access.

WordPress could fail to upload media.

---

71. Possible Better Model

You might instead use:

owner = deployment/admin user
group = www-data

with carefully chosen permissions.

For example, depending on your architecture:

directories → 775
files → 664

can allow group write access.

But this should only be used when the group really needs write access and the security implications are understood.

---

72. Don’t Copy Permission Numbers Blindly

There is no universal:

"WordPress permissions = exactly X"

The correct configuration depends on:

PHP user
deployment user
hosting isolation
automatic updates
plugin behavior
shared hosting model
security requirements

---

73. Hosting Isolation

This becomes especially important when hosting multiple customers.

Suppose:

siteA
siteB
siteC

If all PHP processes run as:

www-data

then they may share the same Unix identity.

That makes isolation weaker.

---

74. Per-Site Users

A stronger hosting design can use:

siteA → user siteA
siteB → user siteB
siteC → user siteC

Then:

PHP-FPM siteA
 ↓
siteA user

PHP-FPM siteB
 ↓
siteB user

Now one site’s process does not automatically have the same filesystem privileges as another site’s process.

---

75. Why Shared www-data Can Be Risky

Suppose:

siteA

is compromised.

If:

siteA PHP
 ↓
www-data

and:

siteB files
 ↓
also writable by www-data

then the compromise could potentially spread into siteB.

Per-site Unix users can reduce this risk.

---

76. This Is How Hosting Becomes Professional

Basic hosting:

All sites
 ↓
www-data
 ↓
same permissions

More isolated hosting:

siteA
 ↓
userA

siteB
 ↓
userB

siteC
 ↓
userC

This is an important architectural improvement for a multi-tenant hosting platform.

---

77. PHP-FPM Pools

PHP-FPM supports separate pools.

Conceptually:

PHP-FPM
│
├── siteA pool → userA
├── siteB pool → userB
└── siteC pool → userC

This can provide better isolation and per-site resource configuration.

---

78. Per-Site Resource Limits

A PHP-FPM pool can have settings controlling:

worker count
process management
user/group
socket

This allows:

siteA
 ↓
5 workers

siteB
 ↓
10 workers

depending on workload.

---

79. Combining Lessons

Now connect:

Users
+
Processes
+
Memory
+
Storage

Example:

siteA PHP-FPM
      │
      ▼
    userA
      │
      ▼
website files
      │
      ▼
RAM

while:

siteB PHP-FPM
      │
      ▼
    userB
      │
      ▼
siteB files

This is much safer than letting every website share the same identity.

---

80. Root vs www-data

Memorize this distinction:

root
=
system administrator authority

www-data
=
service account commonly used by web services

They should not be treated as interchangeable.

---

81. The Dangerous Command

Be very careful with:

rm -rf

especially:

sudo rm -rf

As root, an incorrect path can cause severe damage.

Always verify:

pwd

and:

ls

before destructive operations.

---

82. Another Dangerous Pattern

Avoid casually doing:

chown -R www-data:www-data /

or:

chmod -R 777 /

These can destroy the security and functionality of the entire server.

---

83. Hosting Security Model

A good mental model:

                ROOT
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
   system services      administrators
        │
        ▼
    limited users
        │
        ▼
     websites

Each layer gets only what it needs.

---

84. Essential Commands

Current user

whoami

Identity

id

User information

id www-data

File permissions

ls -la

Path permissions

namei -l /path/to/file

Change ownership

chown

Change permissions

chmod

ACL inspection

getfacl

Groups

groups

Test as another user

sudo -u USER command

---

85. Your Hosting Directory

For:

/storage/websites/learn.cresignsys.com/public

you should be able to answer:

Who owns it?
        ↓
What group owns it?
        ↓
What permissions?
        ↓
Which user runs PHP-FPM?
        ↓
Can that user read it?
        ↓
Can that user write where required?
        ↓
Can Nginx traverse/read it?

If you can answer those questions, you understand the permission layer.

---

86. Complete Hosting Stack

You now have:

                         DOMAIN
                            │
                            ▼
                           DNS
                            │
                            ▼
                            IP
                            │
                            ▼
                         NETWORK
                            │
                            ▼
                         LINUX
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
            CPU            RAM          STORAGE
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                         SYSTEMD
                            │
                            ▼
                         NGINX
                            │
                       process/user
                            │
                            ▼
                        PHP-FPM
                            │
                      process/user
                            │
                            ▼
                        WORDPRESS
                            │
                            ▼
                          MYSQL
                            │
                            ▼
                        DATABASE

And surrounding all of it:

Users
Groups
Permissions
Ownership

---

87. Lesson 054 — Core Principle

The deepest lesson is:

A Linux server doesn’t simply ask “does this file exist?” It asks “who is requesting access, what identity do they have, what permissions apply, and can they traverse the path?”

For hosting:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Unix user
 ↓
Filesystem permissions
 ↓
WordPress

This is the foundation of secure multi-website hosting.

---

Next Lesson — 055

Linux Networking — From Ethernet/VNIC to Port 443

We will now go deeper into the networking layer:

Internet
 ↓
Public IP
 ↓
VNIC
 ↓
Subnet
 ↓
Route table
 ↓
Security rules
 ↓
Linux network interface
 ↓
IP address
 ↓
TCP
 ↓
Port
 ↓
Socket
 ↓
Nginx

Then we will connect it directly to your Oracle Cloud VPS, including why:

DNS correct
+
Nginx running

can still result in:

Connection refused
Connection timed out

and how to determine exactly which layer is blocking the connection.

Linux Storage — From Disk to WordPress Files

We now go one level deeper.

You know:

Internet
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

You also learned that running programs use:

CPU
RAM

Now we need to understand the third major resource:

STORAGE

---

1. What Is Storage?

Storage is where data remains after a process stops or the server reboots.

Examples:

WordPress files
Images
Plugins
Themes
Database files
Logs
Backups
SSL certificates
Configuration files

---

2. RAM vs Storage

Remember:

RAM
=
temporary working memory

Storage
=
persistent data

For example:

WordPress
   ↓
stored on disk

WordPress process
   ↓
uses RAM while running

---

3. Physical Storage

Your VPS ultimately uses some form of physical storage behind the virtualization layer.

It may be backed by:

SSD
NVMe
network-attached block storage
cloud storage

You don’t necessarily see the underlying physical device directly.

---

4. Device

Linux represents storage devices using device files.

For example:

/dev/sda

or:

/dev/vda

or:

/dev/nvme0n1

The exact name depends on the virtual machine and storage configuration.

---

5. Check Your Disks

Run:

lsblk

You may see something like:

NAME        SIZE TYPE
sda         100G disk
├─sda1       99G part
└─sda2        1G part

Your output will depend on your VPS.

---

6. Disk vs Partition

A physical/virtual disk can be divided into:

Partitions

Conceptually:

Disk
│
├── Partition 1
├── Partition 2
└── Partition 3

---

7. Why Partitions?

Partitions allow different portions of a disk to be managed separately.

For example:

Disk
 ↓
Partition
 ↓
Filesystem

A system might have:

/
 /boot
 /home

on separate filesystems or partitions, depending on configuration.

Modern Linux systems can also use LVM, ZFS, Btrfs, RAID, and other storage architectures.

---

8. Filesystem

A partition isn’t automatically a directory full of files.

You generally put a:

Filesystem

on a storage device/partition.

Common Linux filesystems include:

ext4
xfs
btrfs

Ubuntu installations commonly use:

ext4

though your particular server may differ.

---

9. Filesystem Job

The filesystem organizes:

Files
Directories
Metadata
Permissions
Ownership
Inodes
Data blocks

Conceptually:

Disk
 ↓
Partition
 ↓
Filesystem
 ↓
Files

---

10. Mounting

Linux makes a filesystem accessible through a:

Mount Point

For example:

/dev/sda1
      ↓
     /

The filesystem becomes accessible through:

/

---

11. Root Filesystem

Linux has one main filesystem tree beginning at:

/

This is called:

Root directory

Everything appears underneath it.

---

12. Linux Does Not Use Windows-Style Drive Letters

Windows commonly uses:

C:\
D:\

Linux instead uses:

/

and mounts additional filesystems into directories.

---

13. Linux Directory Tree

A simplified Linux filesystem looks like:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── opt
├── proc
├── root
├── run
├── srv
├── storage
├── sys
├── tmp
├── usr
└── var

---

14. /etc

Usually contains system and application configuration.

Examples:

/etc/nginx/
/etc/mysql/
/etc/php/

This is where much of your hosting configuration lives.

---

15. /var

Contains variable data.

Examples:

/var/log/
/var/lib/
/var/cache/

You may find:

/var/log/nginx/

and:

/var/log/mysql/

depending on configuration.

---

16. /usr

Contains many installed programs and supporting files.

For example:

/usr/bin/
/usr/sbin/
/usr/lib/

You may find executable programs such as Nginx-related binaries here depending on the package.

---

17. /home

Often contains normal users’ home directories.

For example:

/home/user/

But web hosting files don’t have to live under /home.

---

18. /root

This is the home directory of the root user:

/root

It is not the same thing as:

/

This distinction is important.

---

19. /tmp

Temporary files are commonly stored here.

/tmp

Do not assume everything in /tmp is permanent.

---

20. /run

Contains runtime state created during boot and while services run.

Examples include:

PID files
Unix sockets
runtime information

You previously saw a PHP-FPM socket such as:

/run/php/php8.3-fpm.sock

---

21. /dev

Contains device interfaces.

For example:

/dev/sda
/dev/null
/dev/random

These are not ordinary files in the usual sense.

---

22. /proc

You already encountered:

/proc

It exposes kernel/process information through a virtual filesystem.

It does not represent ordinary persistent disk storage.

---

23. /sys

Similarly:

/sys

exposes information and interfaces related to devices and the kernel.

---

24. Your Hosting Directory

You have been using a structure similar to:

/storage/websites/

For example:

/storage/websites/learn.cresignsys.com/public/

This is simply a directory in the Linux filesystem.

The important question is:

What filesystem is mounted underneath /storage?

---

25. Check Mounts

Run:

df -h

This shows filesystem usage and mount points.

---

26. Example df -h

You might see:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       100G   40G   60G  40% /

Meaning roughly:

100 GB total
40 GB used
60 GB available

---

27. Why df Is Important

Suppose WordPress reports:

No space left on device

You should check:

df -h

before assuming the WordPress installation is broken.

---

28. But Disk Space Is Not the Only Problem

A filesystem can have:

free storage

but still be unable to create a new file because it has:

no free inodes

This is a deeper Linux storage concept.

---

29. Inode

An:

inode

stores filesystem metadata about a file.

Conceptually:

File
 ↓
inode
 ↓
metadata + pointers to data

Metadata can include things such as:

owner
group
permissions
timestamps
file type
size
data block references

---

30. Filename vs Inode

A directory entry associates:

filename
 ↓
inode

The inode represents the underlying file metadata.

This is a very important Linux filesystem concept.

---

31. Example

Suppose you have:

hello.txt

The filename is not the entire file identity.

Conceptually:

Directory
   │
   └── hello.txt
          ↓
       inode 12345
          ↓
       file data

---

32. Why Inodes Matter for Hosting

Imagine a hosting server containing:

millions of tiny files

The server may have plenty of gigabytes available but run out of inodes.

Then creating new files can fail.

---

33. Check Inodes

Run:

df -i

You may see:

Filesystem     Inodes   IUsed   IFree IUse%
/dev/sda1      6.5M     2M      4.5M  31%

Exact values vary.

---

34. Two Different Storage Problems

Disk capacity

df -h

Inode capacity

df -i

Both matter.

---

35. WordPress Creates Many Files

A WordPress installation can contain:

core files
plugins
themes
uploads
cache
logs
temporary files

A hosting platform with hundreds of sites can accumulate a very large number of files.

---

36. Disk Usage by Directory

Use:

du -sh /storage/*

This gives a high-level size for each directory.

---

37. Find Large Directories

For example:

sudo du -h --max-depth=1 /storage | sort -h

This helps identify which directories consume storage.

---

38. Find Large Websites

If you have:

/storage/websites/

you can inspect:

sudo du -sh /storage/websites/*

You might discover:

site1.com       500M
site2.com       2.1G
site3.com       12G

---

39. Why One Website Can Become Huge

WordPress storage can grow through:

uploads
backups
cache
logs
old plugins
unused themes
database dumps

A site may start at:

500 MB

and eventually become:

20 GB

depending on content and backup strategy.

---

40. Uploads

A common large directory:

wp-content/uploads/

It contains images and other uploaded media.

For a photography website, this could become very large.

---

41. Backups

A common hosting mistake is storing many full backups on the same VPS.

For example:

backup-1.tar.gz
backup-2.tar.gz
backup-3.tar.gz
...

Eventually:

disk full

A production backup strategy should generally include off-server storage.

---

42. Logs

Logs can also grow.

Examples:

/var/log/nginx/
/var/log/mysql/

and application logs.

Linux uses mechanisms such as logrotate and journald to manage many logs, but configurations should still be monitored.

---

43. Log Rotation

Instead of:

access.log

growing forever, you can have:

access.log
access.log.1
access.log.2.gz
...

Old logs can be compressed or deleted according to policy.

---

44. File Permissions

Now we reach one of the most important hosting concepts:

Permissions

Every file and directory has access permissions.

Example:

-rw-r--r--

---

45. Three Permission Categories

Linux permissions traditionally distinguish:

user
group
others

For example:

-rwxr-xr--

means conceptually:

user
rwx

group
r-x

others
r--

---

46. Read

r

means:

Read

For a regular file:

Can read its contents.

---

47. Write

w

means:

Write

For a regular file:

Can modify its contents.

---

48. Execute

x

means:

Execute

For a regular file:

Can execute it as a program, subject to other requirements.

For a directory, x has a different but very important meaning: it allows traversal/search through that directory.

---

49. Directory Permissions

This is a common beginner trap.

For a directory:

r

means roughly:

Can list directory entries.

w

means:

Can create/delete/rename entries, subject to the directory’s other controls.

x

means:

Can traverse/access entries by name.

---

50. Example

A directory:

drwxr-xr-x

means:

d
=
directory

rwx
=
owner

r-x
=
group

r-x
=
others

---

51. Ownership

Every file has an owner and group.

Check with:

ls -l

You might see:

-rw-r--r-- 1 www-data www-data index.php

Meaning:

owner = www-data
group = www-data

---

52. Why www-data?

On Ubuntu/Debian-style systems, web services commonly run under a user such as:

www-data

depending on the service configuration.

This user may need access to website files.

---

53. Your WordPress Directory

For example:

/storage/websites/learn.cresignsys.com/public/

could have ownership:

www-data:www-data

depending on your hosting architecture.

But ownership should be chosen deliberately rather than blindly applied everywhere.

---

54. Permission Problem Example

Suppose WordPress needs to write:

wp-content/uploads/

but PHP-FPM runs as:

www-data

and that directory is not writable by the relevant user/group.

Then WordPress may fail to upload files.

---

55. Another Permission Problem

Suppose Nginx needs to serve:

index.php

but cannot traverse:

/storage/websites/

because a parent directory lacks appropriate execute permissions.

The file itself may be readable, but the path can still be inaccessible.

---

56. Path Permissions Matter

For:

/storage/websites/site/public/index.php

the process needs appropriate access through:

/storage
/storage/websites
/storage/websites/site
/storage/websites/site/public

not just permission on:

index.php

---

57. chmod

chmod changes permissions.

For example:

chmod 644 file.txt

means:

owner = rw-
group = r--
others = r--

---

58. Numeric Permissions

Common values:

4 = read
2 = write
1 = execute

Add them:

7 = rwx
6 = rw-
5 = r-x
4 = r--

---

59. Example 755

755

means:

7 = rwx
5 = r-x
5 = r-x

So:

owner: rwx
group: r-x
others: r-x

---

60. Example 644

644

means:

owner: rw-
group: r--
others: r--

This is commonly suitable for many regular web files, depending on your security model.

---

61. Don’t Blindly Use 777

You may see advice such as:

chmod -R 777 public/

Avoid this as a general solution.

It grants broad write access and can create serious security problems.

---

62. chown

chown changes ownership.

Example:

sudo chown www-data:www-data file.php

This sets:

owner = www-data
group = www-data

---

63. Recursive Ownership

You can use:

sudo chown -R www-data:www-data directory/

But be careful.

Recursive ownership changes can unintentionally affect:

configuration
private files
SSH-related files
deployment files

Always inspect before applying recursively.

---

64. ls -la

Use:

ls -la

to see:

permissions
owner
group
hidden files

This is one of the most useful Linux commands.

---

65. Symbolic Links

Linux also supports:

Symbolic links

or:

symlinks

Example:

current
 ↓
release-2026-08-13

The symlink points to another path.

---

66. Create Symlink

ln -s /path/to/target /path/to/link

Example:

ln -s /storage/websites/site/public /var/www/site

Now:

/var/www/site

points to:

/storage/websites/site/public

---

67. Why Hosting Systems Use Symlinks

A hosting platform might organize:

/storage/websites/site/releases/
/storage/websites/site/current

where:

current

points to the active release.

This can make deployments easier.

---

68. Symlink vs Copy

A symlink:

points to existing data

A copy:

duplicates data

So:

symlink
=
reference

not:

duplicate

---

69. Hard Link

Linux also supports:

Hard links

A hard link is another directory entry referring to the same inode.

Conceptually:

file1
  ↓
 inode 123
  ↑
file2

Both names refer to the same underlying file data.

---

70. Symlink vs Hard Link

Symlink

name
 ↓
path
 ↓
target

Hard link

name1 ─┐
       ├→ same inode
name2 ─┘

This distinction becomes important in advanced filesystem administration.

---

71. Mount Point

Suppose you have:

/storage

and a separate filesystem is mounted there.

Then:

/storage

becomes the entry point to that filesystem.

---

72. Why This Matters for Your Server

You have used:

/storage/websites/

If /storage is a separate mounted disk:

root filesystem
+
storage filesystem

then your website data is separated from the root filesystem.

---

73. Check Mounts

Run:

findmnt

or:

df -h

You may discover:

/dev/sda1 → /
/dev/sdb1 → /storage

---

74. Separate Storage Advantage

Suppose:

/ = 50 GB
/storage = 500 GB

Then:

OS
configs
packages

can remain on:

/

while:

websites
uploads

live on:

/storage

---

75. But Mount Failure Can Be Serious

Imagine /storage normally contains:

/storage/websites/

But after a reboot, the storage filesystem isn’t mounted.

Then:

/storage

may still exist as an ordinary directory on the root filesystem.

Your scripts could accidentally write website data there.

This is a potentially dangerous failure mode.

---

76. Why This Is Dangerous

Suppose:

/storage

is normally a 500 GB filesystem.

After a mount failure:

/storage

might refer only to a directory on /.

A hosting script could continue:

creating websites

and fill the root filesystem instead.

---

77. Check Before Writing

A robust hosting platform should verify:

Is /storage actually mounted?

For example:

mountpoint /storage

If it returns that /storage is not a mountpoint, your automation should investigate before creating sites.

---

78. This Is Important for Your CHP

Your CresignSys Hosting Platform should eventually perform:

Create website
 ↓
Verify /storage mounted
 ↓
Create directory
 ↓
Create Nginx configuration
 ↓
Create database

Don’t assume storage is always mounted.

---

79. Filesystem Read-Only

Another possible failure:

filesystem
 ↓
read-only

Then applications may fail to create or modify files.

Check:

mount

or:

findmnt

for mount options.

---

80. “No Space Left on Device”

This error does not always mean:

df -h = 100%

It can also happen when:

inodes = exhausted

or in other filesystem/resource scenarios.

Therefore check both:

df -h

and:

df -i

---

81. Disk Usage vs Directory Size

This is another important distinction.

du

measures file/directory usage.

df

reports filesystem-level space usage.

They answer different questions.

---

82. Example

Suppose:

df -h

says:

100 GB used

but:

du -sh /*

doesn’t seem to add up.

Possible reasons include:

deleted files still held open by processes
other mounted filesystems
special filesystem accounting

---

83. Deleted but Still Open

This is an advanced but very useful Linux concept.

Suppose a process has:

large.log

open.

Someone deletes the filename:

rm large.log

The directory entry disappears.

But the process still has the file open.

The storage space may not be reclaimed until the process closes it.

---

84. Find Deleted Open Files

You can investigate with:

sudo lsof +L1

This can reveal open files whose directory links have been removed.

---

85. Why This Matters

You might see:

df -h

showing:

90 GB used

while:

du

shows only:

60 GB

A deleted-but-open log file could be part of the explanation.

---

86. WordPress Storage Structure

A typical WordPress installation:

public/
├── wp-admin/
├── wp-content/
│   ├── plugins/
│   ├── themes/
│   └── uploads/
├── wp-includes/
├── index.php
├── wp-config.php
└── ...

---

87. Which Part Usually Grows?

Often:

wp-content/uploads/

grows with media.

Also:

wp-content/cache/

may grow depending on caching software.

Plugins can also generate:

logs
backups
temporary files

---

88. Database Is Also Storage

WordPress’s database is not stored as normal PHP files.

MySQL stores its data in its own data directory and filesystem structures.

Commonly on Ubuntu this is under:

/var/lib/mysql/

depending on configuration.

---

89. So Your Website Uses Multiple Storage Areas

Conceptually:

/storage/websites/site/
        │
        ├── WordPress files
        └── uploads

/var/lib/mysql/
        │
        └── WordPress database

/var/log/
        │
        └── logs

/etc/
        │
        └── configuration

---

90. Backup Must Cover More Than Public Files

A complete WordPress backup usually needs:

WordPress files
+
database

For a hosting server, you may also need to consider:

Nginx configuration
SSL configuration/certificates as appropriate
DNS configuration
server configuration

depending on your recovery plan.

---

91. WordPress File Backup

You might back up:

/storage/websites/site/public/

But that alone does not contain the complete WordPress site state if the database is separate.

---

92. Database Backup

For MySQL, logical backups can be created using tools such as:

mysqldump

or newer MySQL dump tooling.

The exact command depends on your database configuration and authentication setup.

---

93. Full Hosting Backup

A more complete conceptual backup:

Website
│
├── Files
├── Database
├── Nginx config
├── SSL/ACME configuration
└── Metadata

Then store backups somewhere separate from the server.

---

94. Why Off-Server Backup?

If your VPS completely fails:

VPS
 ↓
disk lost

and your only backup is:

same VPS

then:

backup lost too

Therefore production backups should normally include an off-server copy.

---

95. Storage Performance

Storage isn’t only about capacity.

There is also:

IOPS
throughput
latency

---

96. IOPS

IOPS means:

Input/Output Operations Per Second

A storage device might handle many small operations per second.

This matters for workloads such as:

MySQL
WordPress
logs
many small files

---

97. Throughput

Throughput measures how much data can be transferred over time.

For example:

500 MB/s

is a throughput figure.

---

98. Latency

Storage latency is how long an individual operation takes.

For databases, low latency can be very important.

---

99. WordPress and Storage Performance

A busy WordPress server may perform many operations:

PHP
 ↓
read files
 ↓
MySQL
 ↓
read/write database pages
 ↓
logs
 ↓
cache

So storage performance can affect page response time.

---

100. Disk Space Is Not Enough

Two VPSs might both have:

100 GB storage

but perform differently because of:

IOPS
latency
throughput
storage architecture

---

101. Your Complete Storage Model

Memorize:

Physical/virtual storage
        ↓
      device
        ↓
    partition
        ↓
    filesystem
        ↓
      mount
        ↓
   directories
        ↓
      files
        ↓
     inodes
        ↓
   data blocks

And access is controlled by:

ownership
+
permissions

---

102. Your /storage Model

For your server, think:

/storage
   │
   └── websites
        │
        ├── site1.com
        │    └── public
        │
        ├── site2.com
        │    └── public
        │
        └── learn.cresignsys.com
             └── public

Nginx then points each domain to its appropriate document root.

---

103. Nginx Connection

For example:

server {
    server_name learn.cresignsys.com;

    root /storage/websites/learn.cresignsys.com/public;
}

Now the chain becomes:

learn.cresignsys.com
        ↓
DNS
        ↓
VPS
        ↓
Nginx
        ↓
/storage/websites/learn.cresignsys.com/public

---

104. PHP-FPM Connection

Then:

Browser
 ↓
Nginx
 ↓
/storage/websites/learn.cresignsys.com/public
 ↓
PHP file
 ↓
PHP-FPM

The filesystem permissions must allow the appropriate processes to access what they need.

---

105. The Hosting Administrator’s Storage Checklist

When a website cannot write files:

1. Is filesystem mounted?
2. Is disk space available?
3. Are inodes available?
4. Is filesystem read-only?
5. Who owns the directory?
6. What permissions exist?
7. Can PHP-FPM access it?
8. Are parent directories traversable?
9. Is there a quota?
10. Is another filesystem involved?

---

106. Essential Commands

See disks

lsblk

See filesystem space

df -h

See inode usage

df -i

See mounts

findmnt

Check storage mount

mountpoint /storage

Directory size

du -sh /storage

Website sizes

du -sh /storage/websites/*

File ownership

ls -la

Change ownership

chown

Change permissions

chmod

Find open deleted files

sudo lsof +L1

---

107. The Four Major Server Resources

You now understand three very deeply:

CPU
RAM
STORAGE

And earlier:

NETWORK

So a server can be viewed as:

             SERVER
                │
      ┌─────────┼─────────┐
      ▼         ▼         ▼
     CPU       RAM      STORAGE
      │         │         │
      └─────────┼─────────┘
                ▼
             NETWORK

All four interact.

---

108. Example: Website Becomes Slow

Possible cause:

CPU high

or:

RAM pressure

or:

storage I/O slow

or:

network congestion

or:

MySQL slow

or:

PHP-FPM overloaded

This is why good server administration requires understanding the whole stack.

---

109. Complete CresignSys Hosting Stack

You now have:

                         USER
                           │
                           ▼
                         DOMAIN
                           │
                           ▼
                          DNS
                           │
                           ▼
                       PUBLIC IP
                           │
                           ▼
                         NETWORK
                           │
                           ▼
                         UBUNTU
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
             CPU          RAM        STORAGE
              │            │            │
              └────────────┼────────────┘
                           ▼
                       NGINX PROCESS
                           │
                           ▼
                      PHP-FPM PROCESS
                           │
                           ▼
                       WORDPRESS
                           │
                           ▼
                      MYSQL PROCESS
                           │
                           ▼
                        INNODB
                           │
                           ▼
                          DISK

---

Lesson 053 — Core Principle

The most important concept:

A Linux file is not simply “data on disk.” It exists inside a filesystem, is represented by metadata such as an inode, belongs to an owner/group, has permissions, and ultimately maps to storage blocks.

For your hosting platform:

Domain
 ↓
Nginx
 ↓
Document Root
 ↓
Filesystem
 ↓
WordPress files

and:

WordPress
 ↓
MySQL
 ↓
Database files
 ↓
Filesystem
 ↓
Storage

---

Next Lesson — 054

Linux Users, Groups & Permissions — The Security Foundation of Hosting

We will go deeper into:

root
 ↓
user
 ↓
group
 ↓
UID
 ↓
GID
 ↓
www-data
 ↓
file ownership
 ↓
directory traversal
 ↓
chmod
 ↓
chown
 ↓
umask
 ↓
setuid
 ↓
setgid
 ↓
sticky bit

Then we will apply it directly to your hosting structure:

/storage/websites/
        ↓
www-data
        ↓
Nginx
        ↓
PHP-FPM
        ↓
WordPress

and determine exactly who should own your website files and which permissions should be used without resorting to insecure 777 permissions.

Linux Memory — From RAM to WordPress Hosting

We now go one level deeper.

Previously:

Internet
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
Linux processes

Now ask:

Where do those processes actually live while they are running?

The answer begins with:

RAM

---

1. What Is RAM?

RAM means:

Random Access Memory

It is the computer’s fast working memory.

When a program is running:

Program on disk
      ↓
loaded into RAM
      ↓
CPU executes it

---

2. Disk vs RAM

Your VPS has storage:

SSD / NVMe

and memory:

RAM

They are different.

Disk

Stores data persistently:

WordPress files
PHP files
MySQL database
logs
images

RAM

Holds data actively being used:

running programs
temporary data
cached data
kernel data

---

3. RAM Is Temporary

If the server loses power:

RAM
 ↓
contents disappear

But:

SSD
 ↓
data remains

assuming the storage itself isn’t damaged.

---

4. Why Programs Need RAM

Suppose you have:

/usr/sbin/nginx

on disk.

When Nginx runs:

nginx executable
 ↓
RAM
 ↓
process

The CPU works with memory rather than directly executing the program from the storage device in the normal model.

---

5. CPU + RAM

Think:

              CPU
               │
               ▼
              RAM
               │
               ▼
              Disk

Very roughly:

CPU
=
does calculations

RAM
=
working area

Disk
=
persistent storage

---

6. Why RAM Is Faster Than Disk

RAM is designed for fast random access.

Storage devices are persistent but generally slower than RAM for active memory access.

Therefore operating systems try to keep actively used information in memory.

---

7. Linux Memory Is Not Just “Free or Used”

Run:

free -h

You might see something like:

               total   used   free   shared  buff/cache  available
Mem:             8Gi    3Gi    1Gi      ...      ...         ...
Swap:            2Gi    ...    ...

The exact values depend on your server.

---

8. free -h

This is one of the most important commands for server administration:

free -h

The:

-h

means human-readable units.

---

9. Total Memory

Example:

total = 8 GiB

means the system has roughly 8 GiB of RAM available to the operating system, subject to hardware/platform reservations.

---

10. Used Memory

The meaning of “used” depends on the Linux memory accounting model and version.

Don’t immediately assume:

used = bad

Linux intentionally uses otherwise-unused RAM for useful caching.

---

11. Free Memory

free is memory that is currently unused.

But:

Low free memory does not automatically mean the server is out of memory.

Linux can reclaim cache when applications need memory.

---

12. Available Memory

This is one of the most useful values.

Conceptually:

available
=
memory Linux estimates it can make available to applications
without severe memory pressure

So when checking:

free -h

pay close attention to:

available

not just:

free

---

13. Buffers and Cache

Linux uses memory to cache data.

Conceptually:

Disk
 ↓
RAM cache
 ↓
faster future access

For example:

WordPress file
 ↓
read from disk
 ↓
cached in RAM

Later access may be faster.

---

14. Why Linux Uses “Unused” RAM

Suppose:

8 GB RAM

and applications only require:

3 GB

Linux can use some of the remaining memory for:

filesystem cache

instead of leaving it completely idle.

---

15. Cache Can Be Reclaimed

Suppose an application suddenly needs more memory.

Linux can reclaim suitable filesystem cache.

Conceptually:

Cache
 ↓
reclaim
 ↓
RAM available to application

Therefore:

cache ≠ permanently occupied application memory

---

16. Important Hosting Principle

Do not say:

My VPS has only 500 MB free, therefore it is full.

Instead inspect:

free -h

and look at:

available

plus swap and actual process usage.

---

17. Process Memory

Every process consumes memory.

For example:

Nginx
 ↓
RAM

PHP-FPM
 ↓
RAM

MySQL
 ↓
RAM

---

18. Multiple PHP Workers

Suppose PHP-FPM has:

10 workers

Each worker may use some amount of memory.

Conceptually:

PHP worker 1 → 100 MB
PHP worker 2 → 100 MB
PHP worker 3 → 100 MB
...

The actual usage varies substantially by WordPress site, plugins, workload, PHP version, and request.

---

19. Why Worker Count Matters

Suppose you configure:

pm.max_children = 50

That does not mean the server will always consume 50 × some fixed amount.

But under sufficient load, many workers can become active simultaneously.

If each active worker becomes memory-heavy:

many workers
 ↓
high RAM consumption

---

20. Simplified Capacity Model

For planning, think:

Total RAM
-
OS
-
MySQL
-
Nginx
-
PHP-FPM
-
other services
-
safety margin
=
RAM available for growth

This is much more useful than simply counting websites.

---

21. Website Count Does Not Determine RAM

For example:

10 static websites

may require very little application memory.

While:

3 busy WordPress websites

with heavy plugins may require substantially more.

So:

number of websites
≠
memory requirement

---

22. WordPress Is Dynamic

A WordPress request can involve:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
plugins
 ↓
theme
 ↓
database

Each layer can consume resources.

---

23. Example Request

User visits:

https://example.com/shop

The request may trigger:

Nginx
 ↓
PHP worker
 ↓
WordPress
 ↓
WooCommerce
 ↓
plugins
 ↓
MySQL queries

This can require substantially more CPU and RAM than serving a simple static HTML file.

---

24. Virtual Memory

Linux doesn’t simply give every process a raw piece of physical RAM.

It provides:

Virtual Memory

Conceptually:

Process
 ↓
Virtual address space
 ↓
Linux memory management
 ↓
Physical RAM

---

25. Why Virtual Memory?

It gives processes an abstraction where each process has its own virtual address space.

This provides:

isolation
flexibility
memory protection
efficient sharing

---

26. Process Isolation

Imagine:

PHP process A

and:

PHP process B

They should not normally be able to arbitrarily overwrite each other’s memory.

The operating system’s memory protection mechanisms help enforce this separation.

---

27. Virtual Address

A process might use an address such as:

0x7f123456

That is a virtual address.

The CPU’s memory-management hardware and Linux determine where the corresponding data resides in physical memory.

---

28. Pages

Memory is managed in units called:

Pages

A common page size is:

4 KiB

though systems can support other page sizes.

Conceptually:

Virtual memory
│
├── Page
├── Page
├── Page
└── Page

---

29. Page Table

Linux and the CPU use:

Page Tables

to map virtual addresses to physical memory.

Conceptually:

Virtual Page
     ↓
Page Table
     ↓
Physical Page

---

30. Why This Is Powerful

A process can think it has a large continuous address space even though its physical memory may be:

spread across different physical pages

The operating system manages the mapping.

---

31. Memory Protection

Page-level permissions can distinguish memory as:

readable
writable
executable

This is an important part of modern operating-system security.

---

32. Stack

A process has a:

Stack

The stack is commonly used for things such as:

function calls
local variables
return information

Conceptually:

Process
├── Code
├── Heap
├── Stack
└── Other mappings

---

33. Heap

The:

Heap

is memory used dynamically by programs.

For example:

program running
 ↓
needs more dynamic memory
 ↓
heap allocation

PHP and other software make extensive use of dynamically allocated memory.

---

34. Code / Text Segment

The executable code of a program is mapped into memory.

Conceptually:

Process memory
│
├── Code
├── Data
├── Heap
└── Stack

The exact layout is more complex on modern systems.

---

35. Shared Libraries

Programs often use shared libraries.

For example:

PHP
 ↓
shared libraries

Rather than every process keeping a completely separate copy of identical library code, the operating system can share suitable memory pages.

---

36. Shared Memory

Multiple processes can sometimes share memory intentionally.

This can improve efficiency for some workloads.

Conceptually:

Process A
     ↘
      Shared Memory
     ↗
Process B

---

37. Swap

Now we reach an important server concept:

Swap

Swap is storage space that Linux can use as backing for memory pages when appropriate.

It can be:

swap partition

or:

swap file

---

38. Swap File

You previously worked with swapfile concepts on your VPS.

A swap file might be:

/swapfile

Linux can use it as swap space.

---

39. Is Swap RAM?

No.

This distinction is critical.

RAM
=
physical memory

Swap
=
storage used as backing for memory management

---

40. Why Is Swap Much Slower?

RAM is designed for memory access.

Storage is much slower for random memory-style access.

So:

RAM
 ↓
fast

while:

Swap
 ↓
much slower

The exact performance depends on the storage device and workload.

---

41. Swap Is Not a Replacement for RAM

Don’t think:

8 GB RAM
+
8 GB swap
=
16 GB fast RAM

It is not.

A better model is:

8 GB RAM
+
8 GB emergency/backing capacity

with significant performance penalties if heavily relied upon.

---

42. Why Servers Use Swap

A small amount of swap can be useful.

It can provide additional breathing room during temporary memory pressure and can help the system avoid immediate failure in some situations.

But sustained heavy swapping usually indicates insufficient memory or a workload/configuration problem.

---

43. Swap Usage

Check:

free -h

You might see:

Swap:
total
used
free

You can also run:

swapon --show

---

44. swapon --show

This shows configured active swap devices/files.

Example:

/swapfile

---

45. Disk vs Swap

Don’t confuse:

/var/www/

with:

/swapfile

Both may reside on the same SSD, but they serve completely different purposes.

---

46. Memory Pressure

Suppose:

RAM = almost full

and applications keep requesting memory.

Linux may:

reclaim cache
 ↓
compress memory if configured
 ↓
use swap when appropriate
 ↓
eventually encounter allocation failure

---

47. OOM

OOM means:

Out Of Memory

If Linux cannot satisfy memory demands, the system may invoke the:

OOM Killer

---

48. OOM Killer

The Linux kernel can terminate selected processes to recover memory.

Conceptually:

RAM exhausted
      ↓
memory allocation failure
      ↓
OOM handling
      ↓
process killed
      ↓
memory recovered

---

49. Why This Is Dangerous for Hosting

Imagine:

MySQL
PHP-FPM
Nginx

all running.

If memory pressure becomes severe, a critical process could be terminated.

Then:

WordPress
 ↓
database unavailable

or:

Nginx
 ↓
stops responding

---

50. Check Kernel Logs

For memory-related events:

dmesg | grep -i oom

or:

journalctl -k | grep -i oom

Depending on permissions and configuration, you may need:

sudo dmesg

---

51. Memory Monitoring

Use:

free -h

for a quick summary.

Use:

top

for live process-level information.

---

52. top Memory Columns

In top, you’ll see information such as:

VIRT
RES
SHR
%MEM

These require some explanation.

---

53. VIRT

VIRT represents the process’s virtual memory footprint/address space.

It is not the same as physical RAM actually occupied.

Therefore:

VIRT = 2 GB

does not necessarily mean:

RAM = 2 GB

---

54. RES

RES means resident memory.

It is a useful approximation of the amount of physical RAM currently resident for the process, although shared memory accounting means it should not be interpreted as a simple billable per-process total.

---

55. SHR

SHR represents memory associated with shared pages/mappings.

Again, process memory accounting is more complicated than simply adding all RES values.

---

56. Why Can’t You Simply Add Everything?

Suppose:

PHP worker A
RES = 100 MB

PHP worker B
RES = 100 MB

Some pages may be shared.

Therefore:

100 + 100

doesn’t necessarily mean:

200 MB of unique physical RAM

---

57. ps

You can inspect memory usage:

ps aux --sort=-%mem | head

This lists processes sorted by memory usage.

---

58. Find the Biggest Memory Users

A useful command:

ps aux --sort=-rss | head

This sorts approximately by resident memory.

---

59. Typical Hosting Memory Consumers

On a WordPress VPS, significant memory users can include:

MySQL
PHP-FPM
Nginx
system services
monitoring software
control panels
backup tools

The exact ranking varies by workload.

---

60. MySQL Memory

MySQL uses memory for:

buffer pool
connections
sort buffers
temporary structures
table caches
other internal structures

For InnoDB-heavy WordPress installations, the buffer pool is particularly important.

---

61. InnoDB Buffer Pool

We will go deeper later, but understand the basic concept now:

MySQL
 ↓
InnoDB
 ↓
Buffer Pool
 ↓
RAM

The buffer pool caches frequently used table and index pages in memory.

---

62. Why Buffer Pool Helps

Without caching:

query
 ↓
disk
 ↓
data

With a useful cache:

query
 ↓
buffer pool
 ↓
data

Memory access can be much faster than storage access.

---

63. WordPress Memory

A WordPress request can use memory for:

PHP runtime
WordPress core
theme
plugins
query results
objects
buffers

Heavy plugins can increase memory requirements.

---

64. PHP Memory Limit

WordPress/PHP may have limits such as:

memory_limit = 256M

This means a PHP process/request may be restricted by PHP’s memory limit.

It does not mean:

the server has exactly 256 MB for PHP

---

65. PHP Memory Limit vs VPS RAM

Suppose:

VPS RAM = 8 GB

and:

PHP memory_limit = 256M

This does not mean you can safely run:

32 PHP workers

without considering their actual memory use and other processes.

---

66. Worker Capacity

A simplified planning model:

PHP memory per busy worker
×
maximum concurrent workers
=
potential PHP memory demand

Then add:

MySQL
Nginx
OS
other services
safety margin

---

67. Example

Suppose actual PHP worker RSS under your workload is approximately:

80 MB

and you allow:

20 workers

Very roughly:

80 × 20
=
1600 MB

So PHP could potentially consume around:

1.6 GB

under conditions where all 20 workers reach that memory footprint.

This is a planning approximation, not a guaranteed fixed consumption.

---

68. Add MySQL

Suppose:

PHP = 1.6 GB
MySQL = 2 GB
Nginx + OS + other = 1 GB

Then:

≈ 4.6 GB

before additional headroom and caching behavior are considered.

An 8 GB server could be reasonable for such a workload, but actual measurements should drive the final configuration.

---

69. Why “How Many Websites Can I Host?” Has No Simple Answer

Because:

website count

is not the correct capacity metric.

Better metrics are:

requests per second
concurrent PHP requests
PHP worker memory
database workload
database memory
disk I/O
CPU usage
RAM usage

---

70. Static vs WordPress

Compare:

Static HTML

with:

WordPress + WooCommerce + plugins

The second usually requires considerably more server-side processing.

Therefore a server might host:

hundreds of low-traffic static sites

while handling far fewer:

high-traffic dynamic WordPress sites

depending on architecture and resources.

---

71. Memory and Concurrency

This is one of the deepest hosting concepts.

Imagine:

100 visitors

arrive at once.

If every request requires a PHP worker:

100 concurrent PHP requests

could create substantial memory pressure.

But caching can change the situation dramatically.

---

72. Page Cache

If a WordPress page can be served from cache:

Visitor
 ↓
Nginx/page cache
 ↓
HTML

PHP may not run for every request.

This can reduce:

CPU
RAM
database load

---

73. Full-Page Cache

Without cache:

Visitor
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL

With effective full-page caching:

Visitor
 ↓
Cache
 ↓
HTML

This is a major reason caching is important in hosting.

---

74. Object Cache

WordPress can also use object caching.

Conceptually:

WordPress
 ↓
Object Cache
 ↓
cached database-related objects

Systems such as Redis can be used for this purpose.

---

75. Database Cache

MySQL/InnoDB also has its own caching mechanisms.

So a real request can benefit from multiple layers:

Browser cache
 ↓
CDN cache
 ↓
Nginx/page cache
 ↓
Object cache
 ↓
MySQL/InnoDB buffer pool
 ↓
Disk

Each layer can reduce work at the next layer.

---

76. Memory Hierarchy

Now you can see a bigger picture:

CPU registers
      ↓
CPU cache
      ↓
RAM
      ↓
SSD/NVMe
      ↓
Remote storage/network

Generally:

higher
speed
↑

lower
capacity

closer to the CPU.

---

77. Why Caching Exists Everywhere

Caching exists because different storage/memory layers have different speeds.

Example:

CPU
 ↓
L1/L2/L3 cache
 ↓
RAM
 ↓
SSD

A good system tries to keep frequently needed data closer to where it is used.

---

78. Memory Pressure and Hosting

When your server approaches serious memory pressure:

RAM
 ↓
cache reclaim
 ↓
swap
 ↓
slowdown
 ↓
OOM risk

Therefore a professional hosting server should not operate continuously at the absolute edge of available memory.

---

79. Practical Monitoring

Start with:

free -h

Then:

top

Then:

ps aux --sort=-%mem | head -20

Then inspect swap:

swapon --show

---

80. Check Memory Pressure

On Linux systems that expose it, you can inspect:

cat /proc/meminfo

This provides detailed kernel memory accounting.

---

81. /proc/meminfo

You will see values such as:

MemTotal
MemFree
MemAvailable
Buffers
Cached
SwapTotal
SwapFree

There are many more.

Don’t try to memorize them all yet.

---

82. The /proc Filesystem

This introduces another important Linux concept.

/proc

is a virtual filesystem exposing information about:

processes
kernel
memory
CPU
system configuration

It is not an ordinary disk directory containing regular stored files.

---

83. Process Information

For a process:

/proc/PID/

contains information about that process.

For example:

ls /proc/1

shows information related to PID 1.

---

84. Memory Information

cat /proc/meminfo

gives a much deeper view of system memory.

---

85. CPU Information

cat /proc/cpuinfo

shows processor information.

Again, you don’t need to memorize it now.

---

86. Linux Memory Mental Model

Memorize this:

Program
 ↓
Process
 ↓
Virtual Memory
 ↓
Pages
 ↓
Physical RAM

And when RAM becomes constrained:

RAM pressure
 ↓
reclaim cache
 ↓
swap if needed
 ↓
OOM risk

---

87. WordPress Hosting Mental Model

For your VPS:

                 VPS RAM
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
     Nginx       PHP-FPM       MySQL
                    │            │
               PHP workers   Buffer Pool
                    │            │
                    └──────┬─────┘
                           ▼
                       WordPress

The number of PHP workers and the database workload are major capacity considerations.

---

88. Most Important Commands

Memorize these:

free -h

top

ps aux --sort=-%mem | head

swapon --show

cat /proc/meminfo

nproc

---

89. The Complete Architecture So Far

USER
 │
 ▼
DOMAIN
 │
 ▼
DNS
 │
 ▼
IP
 │
 ▼
TCP
 │
 ▼
TLS
 │
 ▼
HTTP
 │
 ▼
NGINX PROCESS
 │
 ▼
PHP-FPM PROCESS
 │
 ▼
WORDPRESS
 │
 ▼
MYSQL PROCESS
 │
 ▼
INNODB BUFFER POOL
 │
 ▼
RAM
 │
 ▼
CACHE / DISK

And underneath everything:

CPU
 +
RAM
 +
STORAGE
 +
LINUX KERNEL

---

Lesson 052 — Core Principle

The key idea is:

RAM is the active working space of the server, and every running service competes for it.

For WordPress hosting, the most important memory consumers are often:

PHP-FPM workers
+
MySQL/InnoDB
+
OS
+
Nginx
+
other services

And the most important capacity concept is:

RAM capacity
≠
number of websites

Instead:

RAM capacity
=
concurrent workload
+
process memory
+
database memory
+
OS/services
+
safety margin

Next Lesson — 053

Linux Storage — From / to Your WordPress Files

We will go deeper into:

Disk
 ↓
Partition
 ↓
Filesystem
 ↓
Mount
 ↓
Directory
 ↓
File
 ↓
Inode
 ↓
Permissions
 ↓
Ownership
 ↓
Hard link
 ↓
Symbolic link
 ↓
Disk space
 ↓
Inode space

Then we will map exactly how your hosting structure works:

/storage/websites/
    ├── domain1/
    ├── domain2/
    ├── learn.cresignsys.com/
    └── shop.cresignsys.com/

and why a website can have plenty of disk space but still fail because of permissions, inodes, mounts, or filesystem problems.