NGINX Là Gì? Cách Hoạt Động, 5 Vai Trò Chính & So Sánh Chi Tiết Với Apache

NGINX là gì mà từ trang lỗi 502 Bad Gateway đến header response của hàng triệu website đều thấy tên nó? Nếu bạn đang phân vân chọn web server cho dự án, hoặc website chậm dần khi lượng truy cập tăng, bài viết này của InterData sẽ giải thích rõ NGINX hoạt động ra sao, dùng để làm gì và khi nào nên chọn nó thay vì Apache.

NGINX là gì?

NGINX là phần mềm web server mã nguồn mở, hiệu năng cao, hoạt động theo kiến trúc event-driven bất đồng bộ. Ngoài việc phục vụ nội dung web, NGINX còn được dùng làm reverse proxy, load balancer, SSL termination và HTTP cache, cho phép một server xử lý hàng chục nghìn kết nối đồng thời với lượng RAM thấp.

NGINX (đọc là “engine-x”) do kỹ sư người Nga Igor Sysoev viết, phát hành bản đầu tiên vào tháng 10 năm 2004. Ông tạo ra nó để giải bài toán C10K: làm sao cho một máy chủ phục vụ được 10.000 kết nối cùng lúc, điều mà mô hình web server truyền thống thời đó xử lý rất tốn tài nguyên.

Năm 2011, Igor Sysoev thành lập công ty NGINX Inc. để phát triển bản thương mại NGINX Plus. Đến năm 2019, F5 Networks mua lại NGINX Inc., và hiện F5 vẫn duy trì song song bản mã nguồn mở miễn phí lẫn bản trả phí.

Nói cách khác, khi ai đó nhắc đến “NGINX server”, họ đang nói về một trong những web server được triển khai nhiều nhất thế giới hiện nay, đứng sau vô số website từ blog cá nhân đến hệ thống lớn như Netflix hay Cloudflare (Cloudflare từng dùng NGINX làm nền tảng proxy trong nhiều năm). Nếu bạn chưa vững khái niệm nền tảng, nên đọc trước bài web server là gì để hiểu vị trí của NGINX trong luồng hoạt động của một website.

NGINX hoạt động như thế nào?

NGINX hoạt động theo mô hình master–worker kết hợp kiến trúc event-driven bất đồng bộ. Master process đọc file cấu hình nginx.conf và quản lý các worker process. Mỗi worker chạy một vòng lặp sự kiện non-blocking, nhờ đó một worker duy nhất xử lý được hàng nghìn kết nối cùng lúc thay vì mỗi kết nối chiếm một tiến trình riêng.

Master process và worker process

Khi bạn khởi động NGINX, có đúng một master process chạy với quyền root. Nó không xử lý request nào cả. Nhiệm vụ của nó là đọc và kiểm tra cấu hình, mở port, rồi sinh ra các worker process chạy với quyền hạn thấp hơn.

Worker mới là nơi xử lý request thật. Số lượng worker thường được đặt bằng số nhân CPU qua chỉ thị worker_processes auto; trong nginx.conf. Mỗi worker lại nhận tối đa số kết nối theo worker_connections, mặc định thường là 768 hoặc 1024 tùy bản đóng gói.

Thiết kế này có một hệ quả rất thực dụng: bạn reload cấu hình mà không rớt kết nối nào. Master sinh worker mới với cấu hình mới, worker cũ xử lý nốt request đang dở rồi tự thoát. Đây là lý do lệnh nginx -s reload an toàn để chạy trên hệ thống production đang có người dùng.

Vì sao kiến trúc event-driven tiết kiệm tài nguyên?

Mô hình cũ kiểu Apache MPM prefork cấp một tiến trình cho mỗi kết nối. 1.000 người truy cập đồng thời nghĩa là 1.000 tiến trình, mỗi tiến trình ngốn vài MB RAM dù phần lớn thời gian chỉ ngồi chờ dữ liệu từ mạng hoặc ổ đĩa.

NGINX làm ngược lại. Worker không chờ. Nó dùng cơ chế thông báo sự kiện của hệ điều hành (epoll trên Linux, kqueue trên FreeBSD) để biết kết nối nào đang sẵn sàng đọc/ghi, rồi xử lý lần lượt trong một vòng lặp. Kết nối đang chờ dữ liệu gần như không tốn gì ngoài một ít bộ nhớ trạng thái.

Kết quả: cùng một VPS 1-2 GB RAM, NGINX giữ được số kết nối đồng thời lớn hơn nhiều so với mô hình process-per-connection. Đó chính là lời giải cho bài toán C10K mà Igor Sysoev nhắm tới từ đầu.

NGINX dùng để làm gì? 5 vai trò chính trong hệ thống thật

NGINX dùng để làm 5 việc chính: phục vụ nội dung tĩnh với vai trò web server, làm reverse proxy đứng trước backend, cân bằng tải giữa nhiều server, kết thúc kết nối SSL/TLS (SSL termination) và cache nội dung để giảm tải. Một bản cài NGINX duy nhất có thể đảm nhận đồng thời nhiều vai trò này.

Web server phục vụ nội dung tĩnh

Đây là vai trò gốc của NGINX server: nhận request HTTP và trả về file HTML, CSS, JavaScript, ảnh, video. Với nội dung tĩnh, NGINX gần như chỉ đọc file từ đĩa và đẩy ra mạng, tận dụng cả cơ chế sendfile của kernel nên tốc độ rất cao và CPU gần như rảnh.

Trong thực tế triển khai, các site landing page, tài liệu tĩnh, website build sẵn bằng Next.js export hoặc Hugo thường chỉ cần một block server vài dòng trong nginx.conf là chạy.

Reverse proxy: NGINX đứng trước backend như thế nào?

Đây là vai trò khiến bạn hay gặp tên NGINX nhất. NGINX không tự chạy code PHP, Python hay Node.js. Nó nhận request từ trình duyệt rồi chuyển tiếp đến backend xử lý động: PHP-FPM cho WordPress/Laravel, một tiến trình Node.js, Gunicorn cho Python. Luồng đi như sau:

Client → NGINX (reverse proxy) → NGINX backend pool (PHP-FPM, Node.js, API…) → NGINX → Client

Cấu hình chuyển tiếp đến backend dùng khối upstream và chỉ thị proxy_pass:

upstream backend_app {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Cách bố trí này giải thích luôn một hiện tượng quen thuộc: khi backend chết, treo hoặc phản hồi sai, NGINX vẫn sống và trả về trang lỗi mang tên nó. Nếu bạn từng thấy màn hình trắng ghi “502 Bad Gateway – nginx”, hãy đọc bài phân tích lỗi 502 Bad Gateway để biết cách khoanh vùng nguyên nhân giữa NGINX và backend.

Load balancer: chia tải cho nhiều server

Khi một backend không gánh nổi lượng truy cập, bạn thêm server và để NGINX chia request. Khối upstream ở trên chính là một load balancer tối giản: mặc định NGINX xoay vòng round-robin giữa các server, ngoài ra còn có least_conn (ưu tiên server ít kết nối nhất) và ip_hash (giữ một client bám một server, cần cho session).

Để hiểu bức tranh rộng hơn về các thuật toán phân phối và health check, bạn nên đọc bài về kỹ thuật load balancing. Còn nếu hệ thống thiên về TCP/Layer 4 hoặc cần tính năng cân bằng tải chuyên sâu, so sánh thêm với HAProxy trước khi chốt công cụ.

SSL termination: gánh phần mã hóa HTTPS

Thay vì để từng backend tự xử lý mã hóa, NGINX nhận kết nối HTTPS từ client, giải mã tại chỗ rồi chuyển request dạng HTTP thường vào mạng nội bộ. Backend nhẹ đi, chứng chỉ SSL quản lý tập trung một chỗ, và bạn bật được HTTP/2 chỉ với listen 443 ssl http2;.

Nếu chưa rõ vì sao mọi website hiện nay đều cần ổ khóa trên trình duyệt, bài viết về giao thức HTTPS giải thích chi tiết cơ chế mã hóa và vai trò của chứng chỉ SSL.

Caching và nén: giảm tải cho backend

NGINX cache được response từ backend bằng proxy_cache: request lặp lại sẽ được trả thẳng từ cache thay vì gọi xuống PHP-FPM hay Node.js lần nữa. Kết hợp nén gzip (hoặc Brotli qua module), dung lượng truyền tải giảm mạnh với nội dung văn bản.

Với website WordPress có lượng đọc lớn nhưng ít thay đổi, bật proxy_cache hoặc fastcgi_cache đúng cách thường là thay đổi mang lại khác biệt tốc độ rõ nhất mà không tốn thêm phần cứng.

So sánh NGINX vs Apache: Chọn web server nào?

NGINX thắng ở hiệu năng nội dung tĩnh, số kết nối đồng thời lớn và vai trò reverse proxy; Apache thắng ở hệ sinh thái module lâu đời và cấu hình phân tán qua .htaccess. Chọn NGINX khi bạn kiểm soát toàn bộ server và ưu tiên hiệu năng; chọn Apache khi phụ thuộc .htaccess hoặc hosting đã cấu hình sẵn.

Trước khi xem bảng, nếu bạn chưa nắm rõ đối thủ lâu đời nhất của NGINX, hãy đọc bài Apache là gì để có nền so sánh công bằng.

Tiêu chí	NGINX	Apache
Kiến trúc xử lý	Event-driven bất đồng bộ, master + worker process	Process/thread theo MPM (prefork, worker, event)
Nội dung tĩnh	Rất nhanh, tiêu thụ RAM thấp khi kết nối lớn	Ổn với tải vừa, tốn RAM hơn khi kết nối tăng cao
Cấu hình thư mục	Không hỗ trợ .htaccess, cấu hình tập trung trong nginx.conf	Hỗ trợ .htaccess, đổi cấu hình theo từng thư mục không cần quyền root
Xử lý nội dung động	Không nhúng trình thông dịch, đẩy sang backend qua FastCGI/proxy	Nhúng được module như mod_php, chạy PHP ngay trong tiến trình
Reverse proxy / load balancing	Là thế mạnh cốt lõi, cấu hình gọn	Làm được qua mod_proxy nhưng ít được chọn cho vai trò này
Phù hợp khi	VPS/Cloud tự quản, traffic cao, làm proxy cho ứng dụng	Hosting cấu hình sẵn, ứng dụng phụ thuộc .htaccess

Quan điểm của người đã vận hành cả hai: nếu bạn thuê VPS và tự dựng từ đầu, hãy chọn NGINX làm mặc định. Chỉ giữ Apache khi ứng dụng của bạn phụ thuộc nặng vào .htaccess mà bạn không muốn viết lại rule, hoặc khi đội ngũ đã quen quản trị Apache. Hai phần mềm này cũng hay được dùng chung: NGINX đứng trước làm proxy, Apache phía sau chạy PHP.

Thị trường không chỉ có hai cái tên này. Trong nhóm web server thương mại, LiteSpeed Web Server nổi bật nhờ tương thích .htaccess như Apache nhưng dùng kiến trúc event-driven như NGINX, kèm plugin cache riêng cho WordPress.

Cách cài đặt NGINX cơ bản trên Ubuntu và CentOS

Cài đặt NGINX từ kho phần mềm hệ điều hành chỉ mất vài phút. Điều kiện tiên quyết: bạn phải có quyền root hoặc sudo trên server. Đây là lý do shared hosting phù hợp giai đoạn nhỏ, còn khi muốn tự cài và làm chủ web server, bạn cần chuyển lên VPS.

Trên Ubuntu/Debian:

# Ubuntu / Debian
sudo apt update
sudo apt install nginx

Trên CentOS/RHEL/AlmaLinux (bản cũ dùng yum thay cho dnf):

# CentOS / RHEL / AlmaLinux
sudo dnf install nginx
sudo systemctl enable --now nginx

Ba lệnh bạn sẽ dùng thường xuyên nhất khi vận hành:

1. Kiểm tra trạng thái: sudo systemctl status nginx — xác nhận NGINX đang chạy và xem log gần nhất.
2. Kiểm tra cú pháp cấu hình: sudo nginx -t — luôn chạy lệnh này trước khi reload, sai một dấu chấm phẩy trong nginx.conf là NGINX từ chối nạp cấu hình.
3. Nạp lại cấu hình không downtime: sudo systemctl reload nginx — worker cũ xử lý nốt request đang dở rồi mới thoát.

Cài xong, mở trình duyệt gõ IP server hoặc chạy curl -I localhost; thấy dòng “Welcome to nginx!” hoặc header Server: nginx là thành công. File cấu hình chính nằm ở /etc/nginx/nginx.conf (đường dẫn có thể khác nếu bạn build từ source). Tài liệu chuẩn về mọi chỉ thị cấu hình nằm tại nginx.org/en/docs.

Bài này chỉ điểm qua phần cài đặt để bạn hình dung mức độ đơn giản. Các bước đầy đủ gồm mở firewall, tạo server block cho domain và trỏ thư mục web đã có trong bài hướng dẫn cài đặt NGINX trên Ubuntu/CentOS.

Hiểu NGINX là gì rồi, nên chạy nó trên hạ tầng nào?

Câu trả lời phụ thuộc vào hai yếu tố: bạn có cần quyền root không, và hệ thống có cần mở rộng nhiều node không. NGINX là phần mềm cài trên hệ điều hành, nên hạ tầng bên dưới quyết định bạn khai thác được bao nhiêu sức mạnh của nó.

• Website/blog/ứng dụng một node: VPS là điểm bắt đầu hợp lý. Bạn có quyền root để cài NGINX, PHP-FPM, database trên cùng một máy; chi phí dễ tiếp cận và đủ cho phần lớn website vừa và nhỏ.
• Hệ thống nhiều backend, traffic biến động: khi NGINX chuyển sang vai trò load balancer đứng trước nhiều node ứng dụng, bạn cần hạ tầng cho phép thêm bớt tài nguyên nhanh — đây là lúc Cloud Server phát huy tác dụng, nhất là mùa campaign hoặc cao điểm bán hàng.
• Đang ở shared hosting: không có gì sai khi ở lại nếu website còn nhỏ. Nhưng shared hosting không cho tự cài web server; thời điểm bạn cần chỉnh nginx.conf, bật HTTP/2 theo ý mình hay dựng reverse proxy chính là thời điểm nâng cấp lên VPS.

FAQ: Giải đáp nhanh các thắc mắc khi tìm hiểu NGINX là gì

NGINX có miễn phí không?

Có. Bản NGINX Open Source phát hành theo giấy phép kiểu BSD, dùng miễn phí cả cho mục đích thương mại và đủ cho phần lớn nhu cầu. F5 bán thêm bản NGINX Plus trả phí với các tính năng như health check chủ động, dashboard giám sát và hỗ trợ chính hãng.

NGINX chạy trên Windows được không?

Được, nginx.org có bản build cho Windows, nhưng chính tài liệu chính thức ghi rõ hiệu năng bản này hạn chế: một worker chỉ xử lý số kết nối giới hạn và thiếu vài tính năng. Windows phù hợp để học và test; môi trường production nên chạy NGINX trên Linux.

Có cần biết Linux để dùng NGINX không?

Cần ở mức cơ bản: SSH vào server, di chuyển thư mục, sửa file bằng nano hoặc vim, chạy lệnh systemctl. Không cần trình độ sysadmin chuyên sâu. Nếu bạn cài được WordPress thủ công một lần theo hướng dẫn, bạn đủ nền để bắt đầu quản lý NGINX.

NGINX có thay được hosting không?

Không. NGINX là phần mềm, hosting hay VPS là hạ tầng để phần mềm đó chạy. Bạn không “mua NGINX thay hosting” được; thứ bạn cần là một server có quyền root, rồi cài NGINX lên đó. Nói cách khác, NGINX thay thế phần mềm web server, không thay thế máy chủ.

Làm sao biết website đang dùng NGINX hay Apache?

Chạy curl -I tenmien.com và nhìn dòng Server: trong header trả về; giá trị “nginx” hoặc “Apache” thường lộ ra ở đây. Lưu ý nhiều hệ thống ẩn hoặc sửa header này vì lý do bảo mật, và website đứng sau CDN sẽ hiển thị tên CDN thay vì web server gốc.

Nội dung kỹ thuật trong bài mang tính tham khảo. Lệnh, đường dẫn file và hành vi mặc định có thể khác nhau giữa Ubuntu/Debian, CentOS/RHEL, giữa các phiên bản NGINX hoặc khi build từ source. Trước khi áp dụng cho hệ thống production, bạn nên kiểm thử trên môi trường staging, sao lưu dữ liệu và cấu hình hiện có, đồng thời đánh giá rủi ro theo đặc thù hệ thống của mình.