NGINX Configuration không chỉ là một tập tin, mà là chìa khóa để điều khiển máy chủ web NGINX của bạn hoạt động hiệu quả, bảo mật và có khả năng mở rộng. Bài viết này sẽ cung cấp một cái nhìn toàn diện về cấu hình NGINX, từ những khái niệm cơ bản đến các trường hợp ứng dụng thực tế và mẹo tối ưu hóa.
Bạn sẽ hiểu rõ vì sao việc nắm vững NGINX Configuration lại quan trọng đến vậy cho mọi hệ thống máy chủ, và làm thế nào để tự tin áp dụng nó vào các dự án của mình. Với hơn 8 năm kinh nghiệm chuyên sâu trong mảng lưu trữ Hosting, VPS và Server tại ZoneCloud, tôi – Võ Đỗ Khuê, đồng sáng lập ZoneCloud, sẽ chia sẻ những kiến thức và trải nghiệm thực tế để giúp bạn làm chủ NGINX Configuration một cách dễ dàng nhất.
NGINX Configuration là gì và tại sao nó quan trọng?
NGINX là gì?
NGINX, phát âm là “engine x”, là một máy chủ web mã nguồn mở mạnh mẽ, được sử dụng rộng rãi trên internet. Nó không chỉ đóng vai trò là một web server mà còn có thể hoạt động như một reverse proxy, bộ cân bằng tải (load balancer), proxy mail và bộ đệm HTTP.
NGINX được Igor Sysoev phát triển lần đầu vào năm 2002 và ra mắt công khai vào năm 2004. Mục tiêu chính của dự án là giải quyết vấn đề C10k, tức là khả năng xử lý 10.000 kết nối đồng thời một cách hiệu quả. Kiến trúc của NGINX là hướng sự kiện và đơn luồng, giúp nó xử lý nhiều kết nối đồng thời với lượng bộ nhớ thấp hơn đáng kể so với các máy chủ truyền thống như Apache. Nhờ vậy, NGINX đặc biệt hiệu quả trong việc phục vụ nội dung tĩnh và quản lý lưu lượng truy cập lớn.
Định nghĩa NGINX Configuration

NGINX Configuration là tập hợp các chỉ thị (directives) và khối lệnh (blocks) được sắp xếp trong các file cấu hình, dùng để điều khiển toàn bộ hoạt động của NGINX. Nó quyết định cách NGINX phản hồi các yêu cầu từ client, xử lý các kết nối, và tương tác với các ứng dụng backend.
Mục đích của việc cấu hình NGINX là để tùy chỉnh hành vi của máy chủ web theo nhu cầu cụ thể của từng ứng dụng hoặc hệ thống. Từ việc định nghĩa cổng lắng nghe, tên miền, đến việc thiết lập các quy tắc phức tạp cho reverse proxy hay cân bằng tải, mọi khía cạnh đều được kiểm soát thông qua NGINX config file.
Vai trò và tầm quan trọng của cấu hình NGINX
Việc cấu hình NGINX đúng cách đóng vai trò cực kỳ quan trọng trong việc đảm bảo sự ổn định và hiệu quả của một hệ thống web. Nó ảnh hưởng trực tiếp đến trải nghiệm người dùng và khả năng vận hành của ứng dụng.
Cấu hình NGINX giúp tối ưu hiệu suất web, đặc biệt là tốc độ tải trang và khả năng xử lý kết nối đồng thời. Một cấu hình tốt có thể giảm đáng kể thời gian phản hồi của máy chủ, cải thiện trải nghiệm người dùng.
Nó cũng tăng cường bảo mật cho ứng dụng và máy chủ web. NGINX có thể được cấu hình để lọc các yêu cầu độc hại, ẩn thông tin máy chủ backend, và thực hiện SSL/TLS termination, bảo vệ hệ thống khỏi các cuộc tấn công phổ biến.
Khả năng mở rộng và linh hoạt của hệ thống cũng được đảm bảo thông qua cấu hình NGINX. Với vai trò là reverse proxy và load balancer, NGINX dễ dàng phân phối lưu lượng truy cập giữa nhiều máy chủ backend, cho phép mở rộng hệ thống theo chiều ngang mà không làm gián đoạn dịch vụ.
NGINX còn đóng vai trò quan trọng trong việc định tuyến yêu cầu và xử lý kết nối hiệu quả. Nó có thể chuyển tiếp các yêu cầu đến đúng ứng dụng hoặc dịch vụ backend dựa trên các quy tắc được định nghĩa, đảm bảo mọi yêu cầu đều được xử lý chính xác.
Trong kiến trúc microservices, NGINX thường được sử dụng làm API Gateway hoặc Ingress Controller. Nó giúp quản lý lưu lượng giữa các dịch vụ nhỏ, cung cấp khả năng định tuyến, cân bằng tải và bảo mật cho toàn bộ hệ thống phân tán.
Cấu trúc cơ bản của một file cấu hình NGINX
Vị trí file cấu hình NGINX
File cấu hình chính của NGINX thường là `nginx.conf`. Vị trí mặc định của file này và các thư mục cấu hình liên quan có thể khác nhau tùy theo hệ điều hành và cách cài đặt.
Trên các hệ thống Linux phổ biến như Ubuntu hoặc CentOS, các file cấu hình NGINX thường nằm trong thư mục `/etc/nginx/`. Bên trong thư mục này, bạn có thể tìm thấy:
- `nginx.conf`: File cấu hình chính.
- `/etc/nginx/conf.d/`: Thư mục chứa các file cấu hình bổ sung, thường được sử dụng để định nghĩa các server block riêng biệt cho từng website.
- `/etc/nginx/sites-available/` và `/etc/nginx/sites-enabled/`: Một số bản phân phối Linux sử dụng cặp thư mục này để quản lý các cấu hình virtual host. Các file cấu hình được tạo trong `sites-available` và được kích hoạt bằng cách tạo symbolic link sang `sites-enabled`.
Cách tổ chức các file cấu hình bằng cách sử dụng chỉ thị `include` là một thực tiễn tốt. Chỉ thị này cho phép bạn chia nhỏ file `nginx.conf` thành nhiều file nhỏ hơn, dễ quản lý hơn, ví dụ: `include /etc/nginx/conf.d/*.conf;`. Điều này giúp giữ cho file cấu hình chính gọn gàng và dễ đọc.
Các ngữ cảnh chính trong NGINX Configuration
File cấu hình NGINX được tổ chức thành các ngữ cảnh (contexts) chính, tạo thành một cấu trúc cây phân cấp. Mỗi ngữ cảnh chứa các chỉ thị áp dụng cho một phạm vi cụ thể.
- `main` context: Đây là ngữ cảnh cấp cao nhất, chứa các chỉ thị toàn cục áp dụng cho toàn bộ NGINX. Các chỉ thị phổ biến bao gồm `user` (người dùng mà NGINX chạy với quyền hạn) và `worker_processes` (số lượng tiến trình worker mà NGINX sẽ khởi tạo).
- `events` context: Ngữ cảnh này nằm trong `main` context và cấu hình các thiết lập liên quan đến xử lý kết nối. Chỉ thị `worker_connections` là một ví dụ, nó xác định số lượng kết nối tối đa mà mỗi tiến trình worker có thể xử lý đồng thời.
- `http` context: Ngữ cảnh `http` chứa các thiết lập chung cho tất cả các HTTP server được định nghĩa. Đây là nơi bạn cấu hình các chỉ thị như `sendfile`, `tcp_nopush`, `tcp_nodelay`, `types_hash_max_size`, và các thiết lập Gzip.
- `server` block: Nằm trong `http` context, mỗi `server` block định nghĩa một virtual host, xử lý các yêu cầu cho một tên miền hoặc địa chỉ IP cụ thể. Các chỉ thị quan trọng trong `server` block bao gồm `listen` (cổng lắng nghe các yêu cầu, ví dụ: 80 cho HTTP, 443 cho HTTPS) và `server_name` (tên miền mà server block này sẽ phản hồi).
- `location` block: Nằm trong `server` block, `location` block định nghĩa cách NGINX xử lý các yêu cầu dựa trên URI (đường dẫn) cụ thể. Ví dụ, `location / { … }` sẽ xử lý tất cả các yêu cầu, trong khi `location /images/ { … }` chỉ xử lý các yêu cầu đến thư mục ảnh.
Ví dụ cấu trúc file NGINX cơ bản
Dưới đây là một ví dụ về cấu trúc file NGINX cơ bản, minh họa cách các ngữ cảnh và chỉ thị được sắp xếp:
“`nginx
main context
user nginx;
worker_processes auto; # Tối ưu NGINX configuration bằng cách tự động điều chỉnh số worker
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
events context
worker_connections 1024; # Số kết nối tối đa mỗi worker có thể xử lý
}
http {
http context
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
server {
server block
listen 80;
server_name your_domain.com www.your_domain.com; # Tên miền của bạn
root /var/www/html; # Thư mục gốc website
index index.html index.htm; # File mặc định
location / {
location block
try_files $uri $uri/ =404;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
}
“`
Ví dụ cấu trúc file NGINX cơ bản này giúp bạn hình dung cách các thành phần tương tác, đặt nền tảng cho việc cấu hình NGINX phức tạp hơn.
Các chỉ thị quan trọng trong NGINX Configuration
Chỉ thị cơ bản
Các chỉ thị này là nền tảng cho mọi cấu hình NGINX, định nghĩa cách máy chủ lắng nghe và phục vụ nội dung.
- `listen`: Chỉ thị này xác định cổng và địa chỉ IP mà NGINX sẽ lắng nghe các kết nối đến. Ví dụ, `listen 80;` cho HTTP hoặc `listen 443 ssl;` cho HTTPS. Bạn cũng có thể chỉ định địa chỉ IP cụ thể, như `listen 192.168.1.100:80;`.
- `server_name`: Chỉ thị này định nghĩa tên miền hoặc các tên host mà server block sẽ phản hồi. Bạn có thể sử dụng nhiều tên miền, ký tự đại diện (wildcard) hoặc biểu thức chính quy. Ví dụ: `server_name example.com www.example.com;` hoặc `server_name *.example.com;`.
- `root`: Chỉ thị `root` xác định thư mục gốc trên hệ thống file nơi NGINX sẽ tìm kiếm các file để phục vụ. Ví dụ, `root /var/www/html;` có nghĩa là NGINX sẽ tìm các file của website trong thư mục `/var/www/html`.
- `index`: Chỉ thị `index` định nghĩa các file mặc định mà NGINX sẽ phục vụ khi một yêu cầu đến một thư mục. Ví dụ, `index index.html index.htm;` sẽ khiến NGINX tìm `index.html` trước, nếu không có thì tìm `index.htm`.
Chỉ thị Reverse Proxy
NGINX là một reverse proxy mạnh mẽ, và các chỉ thị sau đây là cần thiết để cấu hình NGINX reverse proxy.
- `proxy_pass`: Đây là chỉ thị quan trọng nhất để chuyển tiếp yêu cầu đến một máy chủ backend khác. Cú pháp là `proxy_pass http://backend_server_address;`. Ví dụ, `proxy_pass http://localhost:3000;` sẽ chuyển tiếp tất cả yêu cầu đến ứng dụng đang chạy trên cổng 3000.
- `proxy_set_header`: Chỉ thị này cho phép bạn thiết lập hoặc sửa đổi các header của yêu cầu trước khi chuyển tiếp chúng đến máy chủ backend. Các header thường được thiết lập bao gồm `Host`, `X-Real-IP`, `X-Forwarded-For`, và `X-Forwarded-Proto`. Ví dụ:
“`nginx
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
“`
Chỉ thị cho ứng dụng Backend
NGINX hỗ trợ nhiều giao thức để giao tiếp với các ứng dụng backend khác nhau.
- `fastcgi_pass`: Được sử dụng để chuyển tiếp yêu cầu đến một FastCGI server, thường là PHP-FPM. Cú pháp tương tự `proxy_pass`, ví dụ: `fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;` hoặc `fastcgi_pass 127.0.0.1:9000;`.
- `uwsgi_pass`: Dành cho các ứng dụng Python sử dụng giao thức uWSGI.
- `scgi_pass`: Dành cho các ứng dụng sử dụng giao thức SCGI.
Chỉ thị SSL/TLS
Để cấu hình NGINX với SSL/TLS và bật HTTPS, các chỉ thị sau là cần thiết.
- `ssl_certificate`: Chỉ định đường dẫn đầy đủ đến file chứng chỉ SSL (thường là `.crt` hoặc `.pem`). Ví dụ: `ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;`.
- `ssl_certificate_key`: Chỉ định đường dẫn đầy đủ đến file khóa riêng SSL (thường là `.key` hoặc `.pem`). Ví dụ: `ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;`.
- `ssl_protocols`: Xác định các giao thức SSL/TLS được phép sử dụng. Để tăng cường bảo mật, chỉ nên sử dụng các giao thức hiện đại như `TLSv1.2` và `TLSv1.3`. Ví dụ: `ssl_protocols TLSv1.2 TLSv1.3;`.
- `ssl_ciphers`: Định nghĩa các bộ mã hóa (cipher suites) được phép sử dụng. Việc chọn các bộ mã hóa mạnh là rất quan trọng để đảm bảo bảo mật. Ví dụ: `ssl_ciphers ‘ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384’;`.
Chỉ thị Load Balancing

NGINX có thể hoạt động như một load balancer hiệu quả, phân phối lưu lượng truy cập giữa nhiều máy chủ backend.
- `upstream`: Chỉ thị `upstream` được sử dụng để định nghĩa một nhóm các máy chủ backend. Ví dụ:
“`nginx
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
“`
Sau đó, bạn có thể sử dụng `proxy_pass http://backend_servers;` trong một `location` block để chuyển tiếp yêu cầu đến nhóm này.
Các phương pháp cân bằng tải phổ biến bao gồm:
- Round Robin: Đây là phương pháp mặc định, các yêu cầu được phân phối lần lượt đến từng máy chủ trong nhóm.
- Least Connections: Yêu cầu được gửi đến máy chủ có số lượng kết nối đang hoạt động ít nhất.
- IP Hash: Yêu cầu được phân phối dựa trên địa chỉ IP của client, đảm bảo cùng một client luôn được gửi đến cùng một máy chủ.
- Weighted Round Robin: Cho phép bạn gán trọng số cho từng máy chủ, máy chủ có trọng số cao hơn sẽ nhận được nhiều yêu cầu hơn. Ví dụ: `server backend1.example.com weight=3;`.
Các chỉ thị khác
Ngoài các chỉ thị trên, NGINX còn cung cấp nhiều chỉ thị hữu ích khác.
- `rewrite`, `return`: Các chỉ thị này được sử dụng để chuyển hướng URL. `rewrite` cho phép viết lại URL dựa trên biểu thức chính quy, trong khi `return` đơn giản hơn, trả về một mã trạng thái HTTP và URL mới. Ví dụ: `return 301 https://$host$request_uri;` để chuyển hướng HTTP sang HTTPS.
- `error_page`: Chỉ thị này cho phép bạn định nghĩa các trang lỗi tùy chỉnh cho các mã trạng thái HTTP khác nhau. Ví dụ: `error_page 404 /404.html;` sẽ hiển thị file `404.html` khi xảy ra lỗi 404.
Hướng dẫn cấu hình NGINX cho các trường hợp sử dụng phổ biến
Cấu hình NGINX phục vụ website tĩnh
Cấu hình NGINX cơ bản để phục vụ các file tĩnh như HTML, CSS, JavaScript và hình ảnh rất đơn giản và hiệu quả.
Ví dụ cấu hình cơ bản cho một website tĩnh:
“`nginx
server {
listen 80;
server_name your_static_domain.com;
root /var/www/html/your_static_site; # Thư mục chứa các file website tĩnh
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
Cấu hình caching cho các file tĩnh
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control “public, no-transform”;
}
}
“`
Cấu hình này đảm bảo NGINX sẽ tìm các file trong thư mục `/var/www/html/your_static_site` và phục vụ chúng. Đồng thời, nó cũng thiết lập caching cho các loại file tĩnh phổ biến, giúp tăng tốc độ tải trang cho người dùng.
Cấu hình NGINX làm Reverse Proxy
NGINX thường được sử dụng làm reverse proxy để chuyển tiếp yêu cầu đến các ứng dụng backend, giúp tăng cường bảo mật và linh hoạt.
- Cho ứng dụng Node.js (sử dụng Gunicorn/PM2):
“`nginx
server {
listen 80;
server_name your_nodejs_app.com;
location / {
proxy_pass http://localhost:3000; # Chuyển tiếp đến ứng dụng Node.js đang chạy trên cổng 3000
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
“`
- Cho ứng dụng Python (sử dụng Gunicorn/PM2): Tương tự như Node.js, bạn sẽ proxy_pass đến cổng mà Gunicorn hoặc PM2 đang lắng nghe.
“`nginx
server {
listen 80;
server_name your_python_app.com;
location / {
proxy_pass http://localhost:8000; # Chuyển tiếp đến ứng dụng Python đang chạy trên cổng 8000
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
“`
- Cho PHP-FPM: NGINX sẽ giao tiếp với PHP-FPM thông qua giao thức FastCGI.
“`nginx
server {
listen 80;
server_name your_php_app.com;
root /var/www/html/your_php_site;
index index.php index.html;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf; # Bao gồm các thiết lập FastCGI mặc định
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # Đường dẫn socket PHP-FPM
}
}
“`
Cấu hình NGINX làm Load Balancer
Cấu hình NGINX làm load balancer giúp phân phối lưu lượng truy cập giữa nhiều máy chủ backend, tăng khả năng chịu tải và độ sẵn sàng.
Thiết lập `upstream` cho nhiều máy chủ backend:
“`nginx
upstream my_backend_servers {
server 192.168.1.101:8000; # Máy chủ backend 1
server 192.168.1.102:8000; # Máy chủ backend 2
server 192.168.1.103:8000 weight=3; # Ví dụ Weighted Round Robin
}
server {
listen 80;
server_name my_load_balanced_app.com;
location / {
proxy_pass http://my_backend_servers; # Chuyển tiếp yêu cầu đến nhóm máy chủ
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
“`
Ví dụ cân bằng tải Round Robin (mặc định) và Least Connections:
Để sử dụng Least Connections, bạn chỉ cần thêm chỉ thị `least_conn;` vào khối `upstream`:
“`nginx
upstream my_backend_servers_least_conn {
least_conn; # Sử dụng phương pháp Least Connections
server 192.168.1.101:8000;
server 192.168.1.102:8000;
}
“`
Cấu hình SSL/TLS (HTTPS) với Let’s Encrypt
Bật HTTPS là điều cần thiết để bảo mật website. Let’s Encrypt cung cấp chứng chỉ SSL miễn phí và Certbot giúp tự động hóa quá trình này.
Các bước cơ bản để cài đặt Certbot và lấy chứng chỉ:
1. Cài đặt Certbot trên máy chủ của bạn.
2. Chạy lệnh `sudo certbot –nginx -d your_domain.com -d www.your_domain.com` để Certbot tự động lấy chứng chỉ và cấu hình NGINX.
Ví dụ cấu hình HTTPS trong NGINX sau khi Certbot đã cấu hình:
“`nginx
server {
listen 443 ssl http2; # Lắng nghe cổng 443 với SSL và HTTP/2
listen [::]:443 ssl http2;
server_name your_domain.com www.your_domain.com;
ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem; # Đường dẫn chứng chỉ
ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem; # Đường dẫn khóa riêng
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3; # Chỉ dùng giao thức mạnh
ssl_ciphers “ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384”;
ssl_prefer_server_ciphers on;
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
server {
listen 80;
listen [::]:80;
server_name your_domain.com www.your_domain.com;
return 301 https://$host$request_uri; # Chuyển hướng HTTP sang HTTPS
}
“`
Kích hoạt HTTP/2 để tăng tốc độ tải trang

HTTP/2 cải thiện đáng kể hiệu suất tải trang bằng cách cho phép nhiều yêu cầu được gửi qua một kết nối duy nhất. Để kích hoạt HTTP/2, bạn chỉ cần thêm `http2` vào chỉ thị `listen` trong server block HTTPS của mình:
`listen 443 ssl http2;`
Việc này thường được Certbot tự động thêm vào khi bạn cấu hình SSL.
Tối ưu hóa hiệu suất và bảo mật NGINX Configuration
Tối ưu hiệu suất
Để đạt được hiệu suất tối ưu, bạn cần tinh chỉnh một số chỉ thị quan trọng trong cấu hình NGINX.
- Điều chỉnh `worker_processes` và `worker_connections`: `worker_processes` thường nên bằng số lõi CPU của máy chủ để tận dụng tối đa tài nguyên. `worker_connections` xác định số lượng kết nối tối đa mỗi worker có thể xử lý. Việc điều chỉnh hợp lý giúp NGINX xử lý nhiều kết nối đồng thời hơn.
- Bật Gzip Compression cho nội dung web: Nén Gzip giúp giảm kích thước các file văn bản (HTML, CSS, JS) được truyền tải, từ đó giảm băng thông và tăng tốc độ tải trang. Bạn có thể bật Gzip trong `http` context:
“`nginx
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
“`
- Cấu hình Caching tĩnh (`expires` headers): Sử dụng `expires` headers để trình duyệt client lưu trữ các file tĩnh (hình ảnh, CSS, JS) trong một khoảng thời gian nhất định, giảm số lượng yêu cầu đến server.
“`nginx
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control “public, no-transform”;
}
“`
- Sử dụng Keepalive connections để giảm chi phí mạng: `keepalive_timeout` cho phép một kết nối TCP được giữ mở trong một khoảng thời gian nhất định, cho phép nhiều yêu cầu được gửi qua cùng một kết nối, giảm chi phí thiết lập kết nối.
- Tận dụng `epoll` trên Linux cho xử lý sự kiện hiệu suất cao: NGINX tự động sử dụng `epoll` trên Linux nếu có sẵn, đây là một cơ chế xử lý sự kiện hiệu quả cao, giúp NGINX xử lý hàng ngàn kết nối đồng thời một cách nhanh chóng.
Tăng cường bảo mật
Bảo mật web là yếu tố không thể thiếu. NGINX cung cấp nhiều cách để tăng cường bảo mật cho máy chủ của bạn.
- Cập nhật NGINX và hệ điều hành thường xuyên: Đảm bảo bạn luôn sử dụng phiên bản NGINX và hệ điều hành mới nhất để nhận các bản vá bảo mật quan trọng.
- Cấu hình SSL/TLS mạnh mẽ: Chỉ sử dụng các giao thức TLS hiện đại (TLSv1.2, TLSv1.3) và các bộ mã hóa mạnh, đồng thời vô hiệu hóa các giao thức và bộ mã hóa yếu hơn.
- Tắt các module NGINX không cần thiết: Giảm thiểu bề mặt tấn công bằng cách chỉ kích hoạt các module NGINX mà bạn thực sự sử dụng.
- Ẩn thông tin phiên bản NGINX (`server_tokens off;`): Ngăn chặn việc tiết lộ phiên bản NGINX của bạn cho kẻ tấn công, làm giảm thông tin mà chúng có thể sử dụng để khai thác lỗ hổng.
- Kiểm soát truy cập và giới hạn tốc độ (chống tấn công DDoS cơ bản): Sử dụng `allow` và `deny` để kiểm soát truy cập từ các địa chỉ IP cụ thể, và `limit_req_zone` để giới hạn số lượng yêu cầu từ một IP, giúp chống lại các cuộc tấn công DDoS cơ bản.
- Sử dụng Security Headers: Thêm các header bảo mật như `X-Frame-Options`, `X-XSS-Protection`, `Content-Security-Policy` để bảo vệ người dùng khỏi các cuộc tấn công phổ biến trên trình duyệt.
- Thiết lập quyền file an toàn cho các file cấu hình: Đảm bảo các file cấu hình NGINX và các thư mục liên quan có quyền hạn phù hợp, chỉ cho phép người dùng cần thiết truy cập để tránh sửa đổi trái phép.
- Ghi log và giám sát (`access_log`, `error_log`): Cấu hình ghi log chi tiết để theo dõi hoạt động của máy chủ, phát hiện các hành vi bất thường và hỗ trợ khắc phục sự cố bảo mật.
So sánh NGINX và Apache trong cấu hình
Kiến trúc và hiệu suất
- NGINX: Có kiến trúc hướng sự kiện, đơn luồng và không đồng bộ (event-driven, asynchronous). Điều này giúp NGINX rất hiệu quả trong việc xử lý hàng ngàn kết nối đồng thời với lượng bộ nhớ thấp, đặc biệt tốt cho việc phục vụ nội dung tĩnh và làm reverse proxy.
- Apache: Theo truyền thống, Apache sử dụng kiến trúc dựa trên tiến trình/luồng (process-driven, MPM – Multi-Processing Modules). Mỗi kết nối client thường được xử lý bởi một tiến trình hoặc luồng riêng biệt, làm cho nó linh hoạt hơn với nội dung động nhưng có thể tốn tài nguyên hơn khi xử lý tải cao.
Cách thức cấu hình
- NGINX: Cấu hình NGINX tập trung trong file `nginx.conf` và các file `.conf` khác được `include`. Điều này tạo ra một cấu hình rõ ràng, dễ quản lý tại một vị trí duy nhất.
- Apache: Apache sử dụng file `httpd.conf` cho cấu hình chính, nhưng cũng hỗ trợ cấu hình phân tán thông qua các file `.htaccess` đặt trong các thư mục website. Điều này mang lại sự linh hoạt cho người dùng không có quyền truy cập vào cấu hình máy chủ chính.
Tính năng và khả năng mở rộng
- NGINX: Nổi bật với vai trò là reverse proxy, load balancer, HTTP cache và mail proxy. Nó được thiết kế để xử lý tải cao và phân phối lưu lượng hiệu quả, phù hợp với kiến trúc microservices.
- Apache: Là một web server đa năng, hỗ trợ nhiều module động (ví dụ: mod_php, mod_rewrite) cho phép tích hợp sâu với các ứng dụng và cung cấp tính năng phong phú.
Khi nào nên sử dụng NGINX, khi nào nên dùng Apache
- Sử dụng NGINX khi: Bạn cần một reverse proxy, load balancer, HTTP cache hiệu suất cao, hoặc khi phục vụ các website có lưu lượng truy cập lớn và nhiều nội dung tĩnh. NGINX là lựa chọn tuyệt vời cho kiến trúc microservices.
- Sử dụng Apache khi: Bạn cần một web server đa năng với khả năng tích hợp module mạnh mẽ, hoặc khi bạn cần cấu hình phân tán thông qua `.htaccess`. Apache vẫn là lựa chọn tốt cho các ứng dụng PHP truyền thống.
- Kết hợp cả hai: Nhiều hệ thống lớn sử dụng NGINX làm reverse proxy ở phía trước để xử lý các yêu cầu tĩnh, cân bằng tải và bảo mật, sau đó chuyển tiếp các yêu cầu động đến Apache ở backend. Đây là một cấu trúc mạnh mẽ, tận dụng ưu điểm của cả hai.
Kiểm tra và khắc phục lỗi cấu hình NGINX
Kiểm tra cú pháp cấu hình NGINX
Trước khi khởi động lại hoặc tải lại NGINX sau khi thay đổi cấu hình, bạn nên luôn kiểm tra cú pháp của file cấu hình. Lệnh `nginx -t` sẽ kiểm tra xem file cấu hình có lỗi cú pháp nào không mà không cần khởi động lại dịch vụ. Nếu có lỗi, nó sẽ hiển thị thông báo chi tiết về vị trí và loại lỗi.
Xem và phân tích log NGINX
Các file log của NGINX là nguồn thông tin quý giá để chẩn đoán và khắc phục sự cố.
- `access_log`: Ghi lại tất cả các yêu cầu HTTP được NGINX xử lý. Nó cung cấp thông tin về địa chỉ IP của client, thời gian yêu cầu, phương thức HTTP, URL, mã trạng thái, kích thước phản hồi, v.v.
- `error_log`: Ghi lại các lỗi và cảnh báo xảy ra trong quá trình hoạt động của NGINX. Khi gặp sự cố, đây là nơi đầu tiên bạn nên kiểm tra để tìm nguyên nhân.
Các file log này thường nằm trong thư mục `/var/log/nginx/`. Bạn có thể sử dụng các lệnh như `tail -f /var/log/nginx/error.log` để xem log theo thời gian thực.
Các lỗi cấu hình NGINX thường gặp và cách xử lý
- Lỗi cú pháp: Thường do thiếu dấu chấm phẩy (`;`), dấu ngoặc nhọn (`{}`), hoặc sai tên chỉ thị. Lệnh `nginx -t` sẽ giúp bạn phát hiện và sửa những lỗi này.
- Lỗi quyền truy cập file/thư mục: NGINX không thể đọc file cấu hình, file log, hoặc các file website do thiếu quyền. Đảm bảo người dùng NGINX (thường là `nginx` hoặc `www-data`) có quyền đọc cần thiết.
- Cổng đã được sử dụng: Lỗi này xảy ra khi NGINX cố gắng lắng nghe một cổng mà một tiến trình khác đang sử dụng. Kiểm tra bằng lệnh `sudo netstat -tulpn | grep :80` (hoặc cổng tương ứng) để tìm tiến trình đang chiếm cổng.
- `server_name` không khớp: Nếu NGINX không tìm thấy `server_name` phù hợp, nó có thể chuyển yêu cầu đến `server` block mặc định hoặc trả về lỗi. Đảm bảo `server_name` được cấu hình chính xác.
- Lỗi SSL/TLS: Các vấn đề với chứng chỉ hoặc khóa riêng (sai đường dẫn, quyền hạn không đúng, chứng chỉ hết hạn). Kiểm tra kỹ đường dẫn trong `ssl_certificate` và `ssl_certificate_key`.
Câu hỏi thường gặp về NGINX Configuration (FAQs)
NGINX Plus có gì khác biệt so với NGINX mã nguồn mở?
NGINX Plus là phiên bản thương mại của NGINX mã nguồn mở, cung cấp các tính năng nâng cao không có trong phiên bản miễn phí. Các tính năng này bao gồm cân bằng tải nâng cao (ví dụ: session persistence, active health checks), giám sát và quản lý API, tích hợp với các công cụ quản lý, và hỗ trợ kỹ thuật chuyên nghiệp. NGINX Plus được thiết kế cho các môi trường doanh nghiệp yêu cầu hiệu suất cao, độ tin cậy và các tính năng quản lý mở rộng.
Tôi có thể cấu hình NGINX để hoạt động với Docker/Kubernetes không?
Có, NGINX hoạt động rất tốt với Docker và Kubernetes. Trong môi trường Docker, NGINX thường được chạy trong một container riêng biệt, hoạt động như một reverse proxy cho các ứng dụng container khác.
Trong Kubernetes, NGINX được sử dụng phổ biến làm Ingress Controller, định tuyến lưu lượng truy cập từ bên ngoài vào các dịch vụ bên trong cluster. Việc cấu hình NGINX cho Docker/Kubernetes thường liên quan đến việc sử dụng các file cấu hình NGINX tùy chỉnh hoặc các công cụ quản lý Ingress.
Làm thế nào để đảm bảo NGINX của tôi luôn an toàn?
Để đảm bảo NGINX của bạn luôn an toàn, bạn cần thực hiện các biện pháp sau:
- Cập nhật NGINX và hệ điều hành thường xuyên.
- Cấu hình SSL/TLS mạnh mẽ, chỉ sử dụng các giao thức và bộ mã hóa hiện đại.
- Ẩn thông tin phiên bản NGINX (`server_tokens off;`).
- Thiết lập các quy tắc kiểm soát truy cập và giới hạn tốc độ.
- Sử dụng các Security Headers.
- Đảm bảo quyền hạn file và thư mục cấu hình NGINX an toàn.
- Giám sát log NGINX để phát hiện các hoạt động đáng ngờ.
Cấu hình NGINX có phức tạp không đối với người mới bắt đầu?
Cấu hình NGINX ban đầu có thể có vẻ phức tạp đối với người mới bắt đầu do cấu trúc ngữ cảnh và nhiều chỉ thị khác nhau. Tuy nhiên, với các hướng dẫn cấu hình NGINX cơ bản và ví dụ cụ thể, việc làm quen sẽ dễ dàng hơn.
Bắt đầu với các cấu hình đơn giản cho website tĩnh hoặc reverse proxy, sau đó dần dần mở rộng sang các tính năng phức tạp hơn như SSL/TLS hay load balancing. Thực hành và tham khảo tài liệu là chìa khóa để làm chủ NGINX Configuration.
NGINX có thể thay thế hoàn toàn Apache không?
NGINX có thể thay thế Apache trong nhiều trường hợp, đặc biệt là khi cần hiệu suất cao cho nội dung tĩnh, reverse proxy hoặc load balancing. Tuy nhiên, Apache vẫn có những ưu điểm riêng, như khả năng tích hợp module mạnh mẽ và cấu hình phân tán qua `.htaccess`.
Việc lựa chọn hoàn toàn thay thế Apache bằng NGINX phụ thuộc vào yêu cầu cụ thể của ứng dụng và hệ thống. Trong nhiều trường hợp, việc kết hợp cả hai (NGINX làm frontend và Apache làm backend) mang lại hiệu quả tối ưu nhất.