One WordPress Request: Browser → Nginx → PHP-FPM → MySQL

This lesson connects the networking concepts to the actual WordPress server you are operating.

We will follow:

https://templates.cresignsys.com/

from the browser to the server and back.

1. The Complete Architecture

The request travels through:

Browser
   ↓
DNS
   ↓
IP address
   ↓
TCP 443
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
PHP
   ↓
WordPress
   ↓
MySQL
   ↓
Filesystem
   ↓
HTML
   ↓
Nginx
   ↓
TLS
   ↓
Browser

We will now examine each step.

2. The Browser Requests the Website

You type:

https://templates.cresignsys.com/

The browser determines:

Scheme:
https

Hostname:
templates.cresignsys.com

Port:
443

Path:
/

3. DNS

The browser needs the server IP.

Conceptually:

templates.cresignsys.com
          ↓
         DNS
          ↓
      Server IP

For example:

203.0.113.10

The address above is only an example.

4. TCP

The browser establishes a TCP connection:

Client
   │
   │ SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Client
   │
   │ ACK
   ▼
Server

Now:

TCP connection = established

5. TLS

Because the URL uses:

https://

TLS begins.

The browser and server negotiate a secure connection.

The browser also indicates the requested hostname using SNI:

SNI:
templates.cresignsys.com

6. Nginx Presents the Certificate

Your Nginx configuration has access to:

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

and:

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

Nginx uses the TLS configuration to participate in the handshake.

The browser validates the certificate.

7. Secure Channel

After the TLS handshake:

Browser
   │
   │ encrypted TLS data
   ▼
Nginx

The HTTP request is now protected in transit.

8. HTTP Request

Conceptually, the browser sends:

GET / HTTP/1.1
Host: templates.cresignsys.com

A real browser sends many additional headers.

The important idea is:

GET
 ↓
/
 ↓
Host
 ↓
templates.cresignsys.com

9. TLS Decryption

At the server:

Encrypted TLS records
          ↓
         TLS
          ↓
       HTTP data

Nginx/TLS processing obtains the HTTP request.

Now Nginx can process:

GET /
Host: templates.cresignsys.com

10. Nginx Has a Problem to Solve

Nginx asks:

Which website configuration should handle this request?

The server may host:

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

all on the same IP.

11. `server_name`

Your Nginx configuration may contain:

server_name templates.cresignsys.com;

Nginx matches the requested hostname.

Conceptually:

Host:
templates.cresignsys.com
        ↓
Nginx
        ↓
server_name:
templates.cresignsys.com

Now Nginx has selected the correct virtual host.

12. Virtual Host

A virtual host is essentially:

A configuration that tells the web server how to handle a particular website.

Conceptually:

Nginx
 │
 ├── templates.cresignsys.com
 │       ↓
 │     Site A
 │
 ├── learn.cresignsys.com
 │       ↓
 │     Site B
 │
 └── shop.cresignsys.com
         ↓
       Site C

This is the basis of multi-domain hosting.

13. Document Root

The Nginx configuration may specify:

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

This tells Nginx where website files live.

Conceptually:

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

14. What Does `/` Mean?

The browser requested:

GET /

The / means:

Request the root resource of the website.

Nginx needs to determine what file or application should handle it.

15. Static vs Dynamic

Nginx can handle two broad categories.

Static

HTML
CSS
JavaScript
Images
Fonts
PDF

Dynamic

PHP
WordPress
Database-driven pages
APIs

16. WordPress Is Dynamic

A WordPress page isn’t normally stored as:

/about.html

Instead, WordPress generates the response dynamically.

So a request such as:

/about/

may eventually be processed through:

index.php

17. `try_files`

A typical Nginx WordPress configuration often contains logic similar to:

try_files $uri $uri/ /index.php?$args;

The exact configuration can differ.

The basic idea is:

Does requested file exist?
       ↓
YES → serve it
       ↓
NO
       ↓
Send request to WordPress

18. Example: CSS File

Browser requests:

GET /style.css

Nginx checks:

/storage/websites/templates.cresignsys.com/public/style.css

If it exists:

Nginx
 ↓
Read file
 ↓
Return CSS

PHP isn’t needed.

19. Example: WordPress Page

Browser requests:

GET /about/

Nginx checks whether:

/about/

corresponds to a real file/directory.

If not, it may send the request to:

/index.php

Now PHP becomes involved.

20. FastCGI

Nginx commonly communicates with PHP-FPM using:

FastCGI

Conceptually:

Nginx
  ↓
FastCGI
  ↓
PHP-FPM

FastCGI is a protocol/interface for communication between a web server and application processes.

21. Why 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

22. Why Workers?

Imagine 100 users request pages simultaneously.

You don’t want to start an entirely new PHP environment from scratch for every request.

PHP-FPM maintains worker processes that can execute PHP requests.

Conceptually:

100 requests
     ↓
PHP-FPM
     ↓
Worker pool

The exact scheduling behavior depends on PHP-FPM configuration.

23. PHP Socket

Nginx may communicate with PHP-FPM through a Unix socket such as:

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

The exact version/path depends on your server.

Alternatively, PHP-FPM can listen on a TCP socket.

For example:

127.0.0.1:9000

24. Unix Socket vs TCP

Two possible architectures:

Unix socket

Nginx
 ↓
Unix socket
 ↓
PHP-FPM

TCP

Nginx
 ↓
TCP
 ↓
PHP-FPM

For PHP-FPM on the same server, Unix sockets are commonly used.

25. Nginx Sends the PHP Request

Conceptually:

Nginx
 │
 │ "Execute /index.php"
 ▼
PHP-FPM

Nginx also passes relevant request/environment information required by the PHP application.

26. PHP-FPM Executes PHP

PHP-FPM starts/uses a PHP worker.

The worker executes:

index.php

which leads into WordPress.

27. WordPress Bootstrap

WordPress has a large PHP execution flow.

At a simplified level:

index.php
   ↓
wp-blog-header.php
   ↓
wp-load.php
   ↓
wp-config.php
   ↓
WordPress core

The exact internal execution path depends on the request and WordPress version.

28. `wp-config.php`

WordPress needs configuration information.

This includes database connection information.

Conceptually:

WordPress
   ↓
wp-config.php
   ↓
Database configuration

The actual database credentials in your file are sensitive and should never be shared publicly.

29. WordPress Connects to MySQL

Now:

WordPress
    ↓
Database connection
    ↓
MySQL

WordPress asks the database for information.

For example:

Which page is `/about/`?
What is its title?
What is its content?
Which settings apply?

30. Database Is Not the Website

Another important distinction:

MySQL does not contain the entire WordPress website.

WordPress is split between:

Filesystem
+
Database

31. Filesystem Contains

The filesystem contains things such as:

WordPress core
Themes
Plugins
Uploaded media
PHP files
CSS
JavaScript
Configuration

32. Database Contains

The database commonly contains:

Posts
Pages
Users
Settings
Metadata
Comments
Plugin data
Theme-related data

The exact data depends on WordPress and installed plugins.

33. WordPress Combines Both

Conceptually:

                 WordPress
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Filesystem             MySQL
          │                   │
          │                   │
          └─────────┬─────────┘
                    ▼
              Generated page

34. Theme

WordPress determines which theme/template should render the page.

Conceptually:

WordPress
   ↓
Theme
   ↓
Template
   ↓
HTML

The actual template hierarchy is more sophisticated.

35. Plugins

Plugins can modify the request processing.

For example:

Request
 ↓
WordPress
 ↓
Plugin
 ↓
Modify query/content
 ↓
Theme
 ↓
Response

A badly functioning plugin can therefore cause:

500 Internal Server Error

or other application problems.

36. WordPress Generates HTML

Eventually PHP generates something like:

<!doctype html>
<html>
<head>
<title>Templates</title>
</head>
<body>
<h1>Templates</h1>
</body>
</html>

This is generated dynamically.

37. PHP Returns to Nginx

The result flows back:

WordPress
   ↓
PHP
   ↓
PHP-FPM
   ↓
Nginx

Nginx now has the generated response.

38. Nginx Adds/Handles HTTP Response Details

Nginx may handle:

HTTP status
Headers
Compression
Caching
Security headers
Connection handling

depending on configuration.

39. HTTP Response

Conceptually:

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

<!doctype html>
<html>
...
</html>

40. TLS Encrypts the Response

Before the response travels across the Internet:

HTTP response
      ↓
TLS
      ↓
Encrypted TLS records

Then:

TLS
 ↓
TCP
 ↓
IP
 ↓
Internet

41. Browser Receives It

The browser:

Encrypted data
      ↓
TLS
      ↓
HTTP response
      ↓
HTML

Then it parses the HTML.

42. Browser Finds More Resources

Suppose the HTML contains:

<link rel="stylesheet" href="/style.css">
<script src="/app.js"></script>
<img src="/logo.png">

The browser now makes additional requests:

GET /style.css
GET /app.js
GET /logo.png

So the original page causes a chain of additional requests.

43. One Page Can Become Hundreds of Requests

A modern WordPress page might request:

HTML
CSS
JavaScript
Images
Fonts
AJAX/API requests
Analytics
Ads
Third-party resources

Therefore:

One URL
 ↓
Many HTTP requests

44. Browser Rendering

The browser combines:

HTML
+
CSS
+
JavaScript
+
Images
+
Fonts

and produces the visible page.

Conceptually:

HTML
 ↓
DOM

CSS
 ↓
CSSOM

DOM + CSSOM
 ↓
Rendering
 ↓
Pixels

This leads us toward frontend/browser technology.

45. Complete WordPress Request

Now the entire process:

Browser
   │
   │ https://templates.cresignsys.com/
   ▼
DNS
   │
   ▼
Server IP
   │
   ▼
TCP 443
   │
   ▼
TLS
   │
   ▼
HTTP GET /
   │
   ▼
Nginx
   │
   ▼
server_name
   │
   ▼
Document root
   │
   ▼
try_files
   │
   ▼
index.php
   │
   ▼
FastCGI
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ├──────────────┐
   ▼              ▼
Filesystem       MySQL
   │              │
   └──────┬───────┘
          ▼
      WordPress
          │
          ▼
     Theme/Plugins
          │
          ▼
      Generated HTML
          │
          ▼
       PHP-FPM
          │
          ▼
        Nginx
          │
          ▼
         TLS
          │
          ▼
         TCP
          │
          ▼
       Browser

46. Why This Architecture Is Powerful

Each component has a separate responsibility.

DNS
→ Find the server

IP
→ Address the server

TCP
→ Transport data

TLS
→ Secure communication

HTTP
→ Web protocol

Nginx
→ Web server / request routing

FastCGI
→ Web server ↔ PHP communication

PHP-FPM
→ Manage PHP execution

PHP
→ Execute application code

WordPress
→ Web application

MySQL
→ Store application data

Filesystem
→ Store application files

47. Why Separation Matters

Suppose MySQL is down.

Then:

DNS ✓
TCP ✓
TLS ✓
Nginx ✓
PHP-FPM ✓
WordPress ✗
MySQL ✗

The website may produce an application/database error.

But DNS and TLS are perfectly healthy.

48. Another Failure

Suppose PHP-FPM is down:

DNS ✓
TCP ✓
TLS ✓
Nginx ✓
PHP-FPM ✗
WordPress ✗

You might receive:

502 Bad Gateway

49. Another Failure

Suppose Nginx is down:

DNS ✓
TCP ✗
TLS ✗
HTTP ✗

The browser may report a connection failure.

50. Another Failure

Suppose DNS is wrong:

DNS ✗

Everything behind it may appear broken to the user even if:

Nginx ✓
PHP ✓
WordPress ✓
MySQL ✓

This is why layered troubleshooting is so important.

51. Nginx Is the Gateway to Your Applications

Your architecture can be viewed as:

                    INTERNET
                       │
                       ▼
                     NGINX
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Website A    Website B    Website C
          │            │            │
          ▼            ▼            ▼
       PHP-FPM       PHP-FPM       Static
          │            │
          ▼            ▼
      WordPress     WordPress
          │            │
          ▼            ▼
        MySQL        MySQL

This is a simplified architecture; databases and PHP-FPM pools can also be shared or separated depending on design.

52. Why Hosting Panels Exist

This explains why products such as hosting control panels automate many things.

A hosting panel may automate:

Domain creation
DNS integration
Website directory
Nginx configuration
PHP-FPM
Database
SSL
Backups
Users
Logs

Instead of manually configuring each layer.

Your own CresignSys Hosting Platform is essentially trying to automate the same classes of operations.

53. Manual Hosting Creation

Without a hosting panel, creating a WordPress site might involve:

1. DNS
2. Directory
3. Permissions
4. Nginx configuration
5. PHP-FPM configuration
6. Database
7. WordPress files
8. wp-config.php
9. SSL
10. Renewal

Your hosting automation scripts can eventually perform these tasks.

54. A Hosting Automation Pipeline

A future CresignSys hosting script could conceptually do:

Create Website
      ↓
Validate domain
      ↓
Create directory
      ↓
Create database
      ↓
Create database user
      ↓
Create Nginx configuration
      ↓
Enable site
      ↓
nginx -t
      ↓
Reload Nginx
      ↓
Install SSL
      ↓
Configure renewal
      ↓
Install WordPress
      ↓
Return credentials/status

This is the bridge from networking theory to your actual hosting platform.

55. Security Boundaries

Notice that sensitive information exists at different layers.

TLS private key

/etc/letsencrypt/.../privkey.pem

WordPress database credentials

wp-config.php

MySQL credentials

Stored/configured securely.

Linux permissions

Control filesystem access.

Cloud credentials

Control infrastructure.

Each needs separate protection.

56. One Request, Many Processes

A single browser request may involve:

Browser process
      ↓
Operating system networking
      ↓
Nginx process
      ↓
PHP-FPM worker
      ↓
PHP execution
      ↓
WordPress
      ↓
MySQL process
      ↓
Filesystem

This is why web hosting is an excellent practical example of systems engineering.

57. One Important Optimization

Not every request goes through:

Nginx → PHP-FPM → WordPress → MySQL

Static resources can stop earlier:

Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
Response

This is much faster.

58. Caching Changes the Architecture

If a page is cached:

Browser
 ↓
Nginx/cache
 ↓
Cached HTML

WordPress may not need to execute for every request.

With a CDN:

Browser
 ↓
CDN
 ↓
Cache HIT

The request may never reach your VPS at all.

This becomes extremely important when we study performance.

59. The Architecture Evolves

Basic hosting:

Browser
 ↓
Nginx
 ↓
PHP
 ↓
MySQL

More advanced hosting:

Browser
 ↓
CDN
 ↓
Load Balancer
 ↓
Nginx
 ↓
Cache
 ↓
PHP-FPM
 ↓
Application
 ↓
Database
 ↓
Database cache
 ↓
Storage

Modern large-scale hosting can become much more complex.

60. Your Learning Path

You have now completed:

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

The next logical layer is:

Linux Server Architecture

because all of these services are actually running inside your Ubuntu server.

Lesson 030 Summary

The most important chain to remember is:

HTTPS Request
      ↓
Nginx
      ↓
server_name
      ↓
location
      ↓
try_files
      ↓
index.php
      ↓
FastCGI
      ↓
PHP-FPM
      ↓
WordPress
      ↓
MySQL + Filesystem
      ↓
HTML
      ↓
Nginx
      ↓
TLS
      ↓
Browser

And the central principle:

Nginx is the front door; PHP-FPM executes PHP; WordPress is the application; MySQL stores application data; the filesystem stores application files.

Next Lesson — 031

Linux Server Fundamentals

We will now go underneath Nginx and PHP and learn what is actually running your hosting platform:

Hardware
 ↓
CPU
 ↓
RAM
 ↓
Storage
 ↓
Kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Filesystems
 ↓
Network interfaces
 ↓
Sockets
 ↓
systemd
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL

This will explain what your Ubuntu VPS actually is, rather than treating the server as a black box.

CresignSys Learn — Lesson 030

One WordPress Request: Browser → Nginx → PHP-FPM → MySQL

1. The Complete Architecture

2. The Browser Requests the Website

3. DNS

4. TCP

5. TLS

6. Nginx Presents the Certificate

7. Secure Channel

8. HTTP Request

9. TLS Decryption

10. Nginx Has a Problem to Solve

11. server_name

12. Virtual Host

13. Document Root

14. What Does / Mean?

15. Static vs Dynamic

Static

Dynamic

16. WordPress Is Dynamic

17. try_files

18. Example: CSS File

19. Example: WordPress Page

20. FastCGI

FastCGI

21. Why PHP-FPM?

PHP FastCGI Process Manager

22. Why Workers?

23. PHP Socket

24. Unix Socket vs TCP

Unix socket

TCP

25. Nginx Sends the PHP Request

26. PHP-FPM Executes PHP

27. WordPress Bootstrap

28. wp-config.php

29. WordPress Connects to MySQL

30. Database Is Not the Website

31. Filesystem Contains

32. Database Contains

33. WordPress Combines Both

34. Theme

35. Plugins

36. WordPress Generates HTML

37. PHP Returns to Nginx

38. Nginx Adds/Handles HTTP Response Details

39. HTTP Response

40. TLS Encrypts the Response

41. Browser Receives It

42. Browser Finds More Resources

43. One Page Can Become Hundreds of Requests

44. Browser Rendering

45. Complete WordPress Request

46. Why This Architecture Is Powerful

47. Why Separation Matters

48. Another Failure

49. Another Failure

50. Another Failure

51. Nginx Is the Gateway to Your Applications

52. Why Hosting Panels Exist

53. Manual Hosting Creation

54. A Hosting Automation Pipeline

55. Security Boundaries

TLS private key

WordPress database credentials

MySQL credentials

Linux permissions

Cloud credentials

56. One Request, Many Processes

57. One Important Optimization

58. Caching Changes the Architecture

59. The Architecture Evolves

60. Your Learning Path

Linux Server Architecture

Lesson 030 Summary

Next Lesson — 031

Linux Server Fundamentals

Comments

Leave a Reply Cancel reply

More posts

11. `server_name`

14. What Does `/` Mean?

17. `try_files`

28. `wp-config.php`