Tài liệu, Hướng dẫn sử dụng Linux

Hiểu Biết Thuật Toán Chọn Server và Location Block trong Nginx

Đăng vào bởi Nguyễn Trung Văn
Hiểu Biết Thuật Toán Chọn Server và Location Block trong Nginx
12
Th5

Nginx là một trong những máy chủ web phổ biến và mạnh mẽ nhất hiện nay, nổi bật với khả năng xử lý tải trọng cao và hàng nghìn kết nối đồng thời. Nginx có thể hoạt động như một máy chủ web, máy chủ thư điện tử, hoặc như một reverse proxy server hiệu quả.

Để tối ưu hóa cấu hình Nginx, việc sử dụng VPS Windows là lựa chọn lý tưởng cho các dự án web. Với hiệu suất cao và khả năng tùy chỉnh linh hoạt, VPS Windows giúp bạn quản lý server block hiệu quả, đảm bảo website hoạt động mượt mà và ổn định. Khám phá ngay các giải pháp VPS Windows phù hợp!

DataOnline sẽ cùng bạn đi sâu vào những yếu tố quan trọng ảnh hưởng đến cách Nginx xử lý các yêu cầu từ người dùng. Hiểu rõ những khái niệm này sẽ giúp bạn tối ưu hóa thiết kế cấu trúc server và location, làm cho quá trình xử lý yêu cầu trở nên rõ ràng và dễ dàng kiểm soát hơn.

Cấu hình khối trong Nginx

Nginx phân chia một cách logic các cấu hình được thiết kế để phục vụ các nội dung khác nhau thành các khối, sống trong một cấu trúc phân cấp. Mỗi khi có một yêu cầu từ khách hàng, Nginx bắt đầu quá trình xác định khối cấu hình nào sẽ được sử dụng để xử lý yêu cầu đó. Quy trình quyết định này là nội dung chúng ta sẽ thảo luận trong hướng dẫn này.

Các khối chính mà chúng ta sẽ thảo luận bao gồm khối server và khối location.

Khối server là một tập con của cấu hình Nginx định nghĩa một máy chủ ảo dùng để xử lý các yêu cầu thuộc một kiểu xác định. Quản trị viên thường cấu hình nhiều khối server và quyết định khối nào sẽ xử lý kết nối dựa trên tên miền, cổng và địa chỉ IP được yêu cầu.

Khối location nằm trong khối server và được sử dụng để định nghĩa cách Nginx xử lý các yêu cầu đối với các tài nguyên và URI khác nhau của máy chủ cha. Không gian URI có thể được phân chia theo bất cứ cách nào mà quản trị viên mong muốn thông qua các khối này. Đây là một mô hình cực kỳ linh hoạt.

Cách Nginx quyết định khối Server nào sẽ xử lý yêu cầu

Vì Nginx cho phép quản trị viên định nghĩa nhiều khối server hoạt động như các máy chủ web ảo riêng biệt, nên nó cần một quy trình để xác định khối server nào sẽ được sử dụng để đáp ứng một yêu cầu.

Nginx thực hiện điều này thông qua một hệ thống kiểm tra được định nghĩa sẵn nhằm tìm ra sự khớp tốt nhất có thể. Các chỉ thị chính trong khối server mà Nginx quan tâm trong quá trình này là chỉ thị listen và server_name.

Phân tích chỉ thị listen để tìm các khối có thể khớp

Đầu tiên, Nginx xem xét địa chỉ IP và cổng của yêu cầu. Nó so sánh với chỉ thị listen của mỗi server để xây dựng danh sách các khối server có khả năng xử lý yêu cầu đó.

Chỉ thị listen thường xác định địa chỉ IP và cổng mà khối server sẽ phản hồi. Theo mặc định, bất kỳ khối server nào không có chỉ thị listen sẽ được gán giá trị mặc định là 0.0.0.0:80 (hoặc 0.0.0.0:8080 nếu Nginx được chạy bởi người dùng không phải root). Điều này cho phép các khối này phản hồi yêu cầu trên bất kỳ giao diện nào ở cổng 80, tuy nhiên giá trị mặc định này không có tác động lớn trong quá trình lựa chọn server.

Chỉ thị listen có thể được thiết lập như sau:

  • Một kết hợp địa chỉ IP/cổng.
  • Một địa chỉ IP đơn lẻ, khi đó mặc định sẽ sử dụng cổng 80.
  • Một cổng đơn lẻ, khi đó sẽ lắng nghe trên mọi giao diện ở cổng đó.
  • Đường dẫn tới một Unix socket.

Tùy chọn cuối cùng thường chỉ có ý nghĩa khi chuyển yêu cầu giữa các máy chủ khác nhau.

Khi cố gắng xác định khối server nào sẽ nhận yêu cầu, Nginx sẽ ưu tiên dựa trên độ cụ thể của chỉ thị listen theo các quy tắc sau:

  • Nginx dịch tất cả các chỉ thị listen “không đầy đủ” bằng cách thay thế các giá trị bị thiếu bằng giá trị mặc định để mỗi khối có thể được đánh giá theo địa chỉ IP và cổng của nó.
    Một số ví dụ về cách dịch này:

    • Một khối không có chỉ thị listen sử dụng giá trị 0.0.0.0:80.
    • Một khối được thiết lập với địa chỉ IP 111.111.111.111 mà không có cổng sẽ trở thành 111.111.111.111:80.
    • Một khối được thiết lập với cổng 8888 mà không có địa chỉ IP sẽ trở thành 0.0.0.0:8888.

  • Sau đó, Nginx cố gắng thu thập danh sách các khối server khớp với yêu cầu một cách cụ thể nhất dựa trên địa chỉ IP và cổng. Điều này có nghĩa là bất kỳ khối nào sử dụng 0.0.0.0 (để khớp với bất kỳ giao diện nào) sẽ không được lựa chọn nếu có các khối khớp cụ thể với một địa chỉ IP xác định. Trong mọi trường hợp, cổng phải được khớp chính xác.

  • Nếu chỉ có một khối khớp cụ thể nhất, khối server đó sẽ được sử dụng để phục vụ yêu cầu. Nếu có nhiều khối server với mức độ cụ thể bằng nhau, Nginx sẽ chuyển sang đánh giá chỉ thị server_name của từng khối server.

Lưu ý rằng Nginx chỉ đánh giá chỉ thị server_name khi cần phân biệt giữa các khối server có cùng mức độ cụ thể trong chỉ thị listen. Ví dụ, nếu example.com được host trên cổng 80 của 192.168.1.10, một yêu cầu cho example.com sẽ luôn được phục vụ bởi khối đầu tiên trong trường hợp này, bất chấp chỉ thị server_name của khối thứ hai.

server {
    listen 192.168.1.10;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

Trong trường hợp có nhiều khối server khớp với độ cụ thể bằng nhau, bước tiếp theo là kiểm tra chỉ thị server_name.

Phân tích chỉ thị server_name để lựa chọn khối phù hợp

Tiếp theo, để đánh giá các yêu cầu có chỉ thị listen có độ cụ thể bằng nhau, Nginx kiểm tra header Host của yêu cầu. Giá trị này chứa tên miền hoặc địa chỉ IP mà khách hàng thực sự muốn truy cập.

Nginx cố gắng tìm sự khớp tốt nhất cho giá trị được tìm thấy bằng cách xem xét chỉ thị server_name trong từng khối server còn là ứng viên. Quá trình đánh giá diễn ra theo công thức sau:

  • Nginx sẽ cố gắng tìm một khối server có server_name khớp chính xác với giá trị trong header Host của yêu cầu. Nếu tìm thấy, khối đó sẽ được sử dụng để phục vụ yêu cầu. Nếu có nhiều khối khớp chính xác, khối đầu tiên được sử dụng.
  • Nếu không tìm thấy khớp chính xác, Nginx sẽ tìm một khối server có server_name khớp với mẫu bắt đầu bằng ký tự đại diện (được biểu thị bởi dấu * ở đầu tên trong cấu hình). Nếu tìm thấy, khối đó sẽ được sử dụng để phục vụ yêu cầu. Nếu có nhiều khối khớp, khối có sự khớp dài nhất sẽ được sử dụng.
  • Nếu không tìm thấy khớp với ký tự đại diện ở đầu, Nginx tìm kiếm khối server có server_name khớp với mẫu có ký tự đại diện ở cuối (được biểu thị bởi tên kết thúc với dấu * trong cấu hình). Nếu tìm thấy, khối đó sẽ được sử dụng để phục vụ yêu cầu. Nếu có nhiều khối khớp, khối có sự khớp dài nhất sẽ được sử dụng.
  • Nếu không tìm thấy khớp nào với mẫu ký tự đại diện ở cuối, Nginx đánh giá các khối server có server_name được định nghĩa bằng biểu thức chính quy (được biểu thị bởi ký tự ~ đứng trước tên).
    • Biểu thức chính quy đầu tiên khớp với header Host sẽ được chọn để phục vụ yêu cầu.
  • Nếu không tìm thấy khớp bằng biểu thức chính quy, Nginx sẽ chọn khối server mặc định cho địa chỉ IP và cổng đó.

Mỗi kết hợp địa chỉ IP/cổng có một khối server mặc định được sử dụng khi không thể xác định hành động cụ thể dựa trên các phương pháp trên. Đối với mỗi kết hợp địa chỉ IP/cổng, khối mặc định này sẽ là khối đầu tiên trong cấu hình hoặc khối chứa tùy chọn default_server trong chỉ thị listen (tùy chọn này sẽ ghi đè thuật toán “khối đầu tiên được tìm thấy”). Chỉ có thể có một khai báo default_server cho mỗi kết hợp địa chỉ IP/cổng.

Ví dụ

Nếu có một server_name được định nghĩa mà khớp chính xác với giá trị của header Host, thì khối server đó sẽ được chọn để xử lý yêu cầu.

Ví dụ, nếu header Host của yêu cầu được thiết lập thành host1.example.com, thì khối server thứ hai sẽ được chọn:

server {
    listen 80;
    server_name *.example.com;

    . . .

}

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

Nếu không có khối nào khớp chính xác, Nginx kiểm tra xem có server_name với ký tự đại diện đứng đầu khớp hay không. Khối với mẫu bắt đầu bằng ký tự đại diện có sự khớp dài nhất sẽ được chọn để xử lý yêu cầu.

Ví dụ, nếu yêu cầu có header Host là www.example.org, thì khối server thứ hai sẽ được chọn:

server {
    listen 80;
    server_name www.example.*;

    . . .

}

server {
    listen 80;
    server_name *.example.org;

    . . .

}

server {
    listen 80;
    server_name *.org;

    . . .

}

Nếu không tìm thấy khối nào khớp với ký tự đại diện đứng đầu, Nginx sẽ kiểm tra xem có khối nào khớp với mẫu có ký tự đại diện ở cuối hay không. Lúc này, khối có sự khớp dài nhất với ký tự đại diện ở cuối sẽ được chọn để phục vụ yêu cầu.

Ví dụ, nếu header Host của yêu cầu là www.example.com, thì khối server thứ ba sẽ được chọn:

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name www.example.*;

    . . .

}

Nếu không có mẫu nào khớp với ký tự đại diện, Nginx sẽ chuyển sang kiểm tra các chỉ thị server_name sử dụng biểu thức chính quy. Khối server đầu tiên có biểu thức chính quy khớp sẽ được chọn để phản hồi yêu cầu.

Ví dụ, nếu header Host của yêu cầu được thiết lập thành www.example.com, thì khối server thứ hai sẽ được chọn:

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name ~^(www|host1).*\.example\.com$;

    . . .

}

server {
    listen 80;
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;

    . . .

}

Nếu không bước nào ở trên thỏa mãn yêu cầu, thì yêu cầu sẽ được chuyển đến khối server mặc định cho địa chỉ IP và cổng tương ứng.

Khớp Location Blocks

Tương tự như quy trình Nginx sử dụng để lựa chọn khối server xử lý yêu cầu, Nginx cũng có thuật toán đã được thiết lập để quyết định khối location nào trong server sẽ được sử dụng để xử lý yêu cầu.

Cú pháp Location Block

Trước khi đi vào cách Nginx lựa chọn khối location để xử lý yêu cầu, hãy cùng xem qua một số cú pháp thường gặp trong định nghĩa location block. Các khối location được đặt trong các khối server (hoặc khối location khác) và được dùng để quyết định cách xử lý URI của yêu cầu (phần của yêu cầu xuất hiện sau tên miền hoặc địa chỉ IP/cổng)

Các khối location thường có dạng:

location optional_modifier location_match {

    . . .

}

Trong đó, location_match định nghĩa nội dung mà Nginx sẽ kiểm tra trong URI của yêu cầu.

Sự tồn tại hay không của modifier trong ví dụ trên ảnh hưởng đến cách Nginx cố gắng khớp khối location. Các modifier sau đây sẽ khiến cho khối location được diễn giải theo các cách như sau:

  • (none): Nếu không có modifier nào, location được diễn giải theo dạng khớp tiền tố. Điều này có nghĩa là chuỗi location được đưa ra sẽ được so sánh với phần đầu của URI của yêu cầu để xác định sự khớp.
  • =: Nếu có dấu bằng, khối này sẽ được coi là khớp nếu URI của yêu cầu khớp chính xác với chuỗi location đã cho.
  • ~: Nếu có dấu tilde, location sẽ được diễn giải theo dạng khớp biểu thức chính quy phân biệt chữ hoa chữ thường.
  • ~*: Nếu có kết hợp tilde và dấu sao, khối location sẽ được diễn giải theo dạng khớp biểu thức chính quy không phân biệt chữ hoa chữ thường.
  • ^~: Nếu có kết hợp dấu mũ và tilde, và nếu khối này được chọn là khối khớp không dùng biểu thức chính quy tốt nhất, thì việc so khớp biểu thức chính quy sẽ không được thực hiện.

Ví dụ về cú pháp Location Block

Ví dụ về khớp tiền tố, khối location sau có thể được chọn để phản hồi các URI như /site, /site/page1/index.html, hoặc /site/index.html:

location /site {

    . . .

}

Để minh họa cho khớp chính xác của URI, khối dưới đây luôn được sử dụng để phản hồi một URI chính xác là /page1. Nó sẽ không được dùng để xử lý URI /page1/index.html. Lưu ý rằng nếu khối này được chọn và yêu cầu được xử lý bằng một trang index, một redirect nội bộ sẽ xảy ra tới một location khác thực sự xử lý yêu cầu:

location = /page1 {

    . . .

}

Ví dụ về khối location được diễn giải theo dạng biểu thức chính quy phân biệt chữ hoa chữ thường:
Khối này có thể được dùng để xử lý yêu cầu cho /tortoise.jpg, nhưng không áp dụng cho /FLOWER.PNG:

location ~ \.(jpe?g|png|gif|ico)$ {

    . . .

}

Khối cho phép khớp không phân biệt chữ hoa chữ thường tương tự như ví dụ trên:

location ~* \.(jpe?g|png|gif|ico)$ {

    . . .

}

Cuối cùng, khối dưới đây sẽ ngăn chặn việc so khớp biểu thức chính quy nếu khối này được xác định là khối khớp không dùng biểu thức chính quy tốt nhất. Nó có thể xử lý yêu cầu cho /costumes/ninja.html:

location ^~ /costumes {

    . . .

}

Như bạn thấy, các modifier cho biết cách khối location sẽ được diễn giải. Tuy nhiên, điều này không cho ta biết thuật toán Nginx sử dụng để quyết định khối location nào sẽ nhận yêu cầu. Phần tiếp theo sẽ giải thích chi tiết.

Cách Nginx lựa chọn Location để xử lý yêu cầu

Nginx lựa chọn khối location để phục vụ yêu cầu theo cách tương tự như việc lựa chọn khối server. Nó chạy qua một quy trình xác định khối location tốt nhất cho bất kỳ yêu cầu nào. Việc hiểu rõ quy trình này là rất quan trọng để có thể cấu hình Nginx một cách chính xác và tin cậy.

Nhớ rằng, dựa trên các loại khai báo location đã nêu ở trên, Nginx đánh giá các bối cảnh location có khả năng khớp bằng cách so sánh URI của yêu cầu với từng location. Quá trình này diễn ra theo thuật toán sau:

  • Nginx bắt đầu bằng cách kiểm tra tất cả các khối location dựa trên tiền tố (các loại location không sử dụng biểu thức chính quy). Nó kiểm tra từng location với toàn bộ URI của yêu cầu.
  • Đầu tiên, Nginx tìm kiếm một khối khớp chính xác. Nếu có một khối location sử dụng modifier = khớp chính xác với URI của yêu cầu, khối location đó sẽ được chọn ngay lập tức để phục vụ yêu cầu.
  • Nếu không có khối nào khớp chính xác (sử dụng modifier =), Nginx chuyển sang đánh giá các tiền tố không chính xác. Nó tìm ra khối location có tiền tố khớp dài nhất với URI của yêu cầu, và tiến hành đánh giá như sau:
    • Nếu khối location khớp tiền tố dài nhất có modifier ^~, thì Nginx sẽ dừng ngay việc tìm kiếm và chọn khối đó để phục vụ yêu cầu.
    • Nếu khối location khớp tiền tố dài nhất không sử dụng modifier ^~, kết quả khớp được lưu tạm thời để Nginx có thể chuyển sang bước tìm kiếm tiếp theo.
  • Sau khi xác định được khối location tiền tố khớp dài nhất và lưu kết quả, Nginx tiếp tục đánh giá các khối location sử dụng biểu thức chính quy (bao gồm cả phân biệt và không phân biệt chữ hoa chữ thường). Nếu có bất kỳ khối location nào sử dụng biểu thức chính quy nằm trong khối location tiền tố dài nhất, Nginx sẽ ưu tiên đưa chúng lên đầu danh sách kiểm tra. Nginx tiến hành so khớp với các khối biểu thức chính quy theo thứ tự. Khối biểu thức chính quy đầu tiên khớp với URI của yêu cầu sẽ được chọn ngay lập tức để phục vụ yêu cầu.
  • Nếu không có khối location nào sử dụng biểu thức chính quy khớp với URI, thì khối location tiền tố được lưu trước đó sẽ được chọn để phục vụ yêu cầu.

Điều quan trọng cần hiểu là, theo mặc định, Nginx sẽ phục vụ các khối khớp biểu thức chính quy ưu tiên hơn các khối tiền tố. Tuy nhiên, nó đánh giá các khối tiền tố trước, cho phép quản trị viên ghi đè xu hướng này bằng cách sử dụng các modifier như = và ^~.

Cũng cần lưu ý rằng, mặc dù các location tiền tố thường được chọn dựa trên sự khớp dài nhất và cụ thể nhất, nhưng việc đánh giá biểu thức chính quy sẽ dừng lại ngay khi khối khớp đầu tiên được tìm thấy. Điều này có nghĩa là vị trí của các khối biểu thức chính quy trong cấu hình có ảnh hưởng rất lớn.

Cuối cùng, cần hiểu rằng, các khối biểu thức chính quy nằm trong khối tiền tố khớp dài nhất sẽ “nhảy lên hàng đầu” khi Nginx đánh giá các khối regex. Chúng sẽ được đánh giá theo thứ tự trước khi xem xét các khối regex khác. Maxim Dounin, một lập trình viên Nginx rất hữu ích, đã giải thích phần này của thuật toán lựa chọn trong một bài viết.

Khi nào việc đánh giá Location Block chuyển sang các Location khác?

Nói chung, khi một khối location được chọn để phục vụ yêu cầu, quá trình xử lý yêu cầu sẽ diễn ra hoàn toàn trong bối cảnh của khối đó từ thời điểm đó trở đi. Chỉ có khối location được chọn và các chỉ thị kế thừa mới quyết định cách xử lý yêu cầu, mà không bị ảnh hưởng bởi các khối location cùng cấp.

Mặc dù đây là quy tắc chung cho phép bạn thiết kế các khối location một cách dự đoán được, nhưng điều quan trọng là phải nhận ra rằng có những trường hợp mà một tìm kiếm location mới sẽ được kích hoạt bởi một số chỉ thị trong khối location đã chọn. Những ngoại lệ với quy tắc “chỉ có một khối location” có thể ảnh hưởng đến cách thức thực sự xử lý yêu cầu và có thể không phù hợp với kỳ vọng của bạn khi thiết kế các khối location.

Một số chỉ thị có thể dẫn đến redirect nội bộ như sau:

  • index
  • try_files
  • rewrite
  • error_page

Hãy cùng xem qua một số trường hợp:

Chỉ thị index luôn dẫn đến một redirect nội bộ nếu nó được sử dụng để xử lý yêu cầu. Các khối location khớp chính xác thường được dùng để tăng tốc quá trình lựa chọn bằng cách kết thúc ngay thuật toán. Tuy nhiên, nếu bạn tạo một khối location khớp chính xác cho một thư mục, rất có thể yêu cầu sẽ được redirect tới một location khác để xử lý thực tế.

Ví dụ, trong trường hợp dưới đây, khối location đầu tiên được khớp bởi URI /exact, nhưng để xử lý yêu cầu, chỉ thị index được kế thừa trong khối đã kích hoạt một redirect nội bộ sang khối thứ hai:

index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

Nếu bạn thực sự cần xử lý yêu cầu trong cùng một khối, bạn sẽ cần sử dụng phương pháp khác để đáp ứng yêu cầu của thư mục đó. Ví dụ, bạn có thể đặt một giá trị index không hợp lệ cho khối đó và bật autoindex:

location = /exact {
    index nothing_will_match;
    autoindex on;
}

location  / {

    . . .

}

Chỉ thị try_files cho Nginx biết kiểm tra sự tồn tại của một tập hợp các tệp hoặc thư mục. Tham số cuối cùng có thể là một URI mà Nginx sẽ redirect nội bộ tới.

Xem ví dụ sau:

root /var/www/main;
location / {
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

Trong ví dụ trên, nếu có một yêu cầu cho /blahblah, khối location đầu tiên sẽ nhận yêu cầu. Nó sẽ thử tìm tệp có tên blahblah trong thư mục /var/www/main. Nếu không tìm thấy, nó sẽ thử tìm tệp blahblah.html, sau đó kiểm tra xem có thư mục blahblah/ hay không trong /var/www/main. Nếu tất cả các nỗ lực này đều thất bại, nó sẽ redirect nội bộ tới /fallback/index.html. Điều này kích hoạt một tìm kiếm location mới, dẫn đến khối location thứ hai, và tệp /var/www/another/fallback/index.html sẽ được phục vụ.

Một chỉ thị khác có thể dẫn đến chuyển đổi location là rewrite. Khi sử dụng tham số cuối cùng với chỉ thị rewrite, hoặc khi không sử dụng tham số nào, Nginx sẽ tìm kiếm location mới khớp với kết quả của rewrite.

Ví dụ, nếu ta sửa đổi ví dụ trên để bao gồm rewrite, ta sẽ thấy yêu cầu đôi khi được chuyển trực tiếp sang khối location thứ hai mà không cần dựa vào try_files:

root /var/www/main;
location / {
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

Trong ví dụ trên, một yêu cầu cho /rewriteme/hello ban đầu sẽ được khối location đầu tiên xử lý. Yêu cầu sẽ được rewrite thành /hello và sau đó một tìm kiếm location mới sẽ được thực hiện. Trong trường hợp này, nó sẽ khớp với khối location đầu tiên một lần nữa và được xử lý bởi try_files như bình thường, có thể chuyển sang /fallback/index.html nếu không tìm thấy tệp nào (sử dụng redirect nội bộ của try_files mà chúng ta đã thảo luận ở trên).

Tuy nhiên, nếu có một yêu cầu cho /rewriteme/fallback/hello, khối location đầu tiên vẫn sẽ khớp. Rewrite sẽ được áp dụng một lần nữa, lần này chuyển thành /fallback/hello. Yêu cầu sau đó sẽ được phục vụ bởi khối location thứ hai.

Một tình huống tương tự xảy ra với chỉ thị return khi gửi mã trạng thái 301 hoặc 302. Sự khác biệt ở đây là nó tạo ra một yêu cầu hoàn toàn mới dưới dạng redirect hiển thị bên ngoài. Tình huống này cũng có thể xảy ra với chỉ thị rewrite khi sử dụng tham số redirect hoặc permanent. Tuy nhiên, các tìm kiếm location như vậy không nên gây bất ngờ, vì redirect hiển thị bên ngoài luôn dẫn đến một yêu cầu mới.

Chỉ thị error_page có thể dẫn đến một redirect nội bộ tương tự như cách mà try_files tạo ra. Chỉ thị này được dùng để định nghĩa hành động cần thực hiện khi gặp các mã trạng thái nhất định. Trong hầu hết các trường hợp, chỉ thị này sẽ không được thực thi nếu đã thiết lập try_files, bởi vì try_files xử lý toàn bộ vòng đời của yêu cầu.

Hãy xem xét ví dụ sau:

root /var/www/main;

location / {
    error_page 404 /another/whoops.html;
}

location /another {
    root /var/www;
}

Mọi yêu cầu (ngoại trừ các yêu cầu bắt đầu bằng /another) sẽ được xử lý bởi khối location đầu tiên, phục vụ các tệp từ /var/www/main. Tuy nhiên, nếu không tìm thấy tệp (mã trạng thái 404), một redirect nội bộ tới /another/whoops.html sẽ xảy ra, dẫn đến tìm kiếm location mới và cuối cùng khối location thứ hai sẽ được sử dụng để phục vụ tệp /var/www/another/whoops.html.

Như bạn thấy, hiểu được các trường hợp khi Nginx kích hoạt một tìm kiếm location mới sẽ giúp dự đoán hành vi khi xử lý các yêu cầu.

Kết luận

Hiểu cách Nginx xử lý các yêu cầu từ khách hàng sẽ giúp bạn quản lý và tối ưu hóa các tác vụ quản trị hệ thống một cách hiệu quả. Bạn sẽ có khả năng xác định chính xác khối server mà Nginx sẽ lựa chọn dựa trên từng yêu cầu của khách hàng. Bên cạnh đó, bạn cũng sẽ biết cách Nginx chọn khối location phù hợp dựa trên URI của yêu cầu. Tổng thể, việc nắm vững quy trình lựa chọn các khối này sẽ giúp bạn dễ dàng truy vết và phân tích các bối cảnh mà Nginx áp dụng để phục vụ từng yêu cầu cụ thể.

Khi triển khai Nginx với các location block, việc thuê máy chủ VPS chất lượng là yếu tố then chốt. Một máy chủ VPS mạnh mẽ hỗ trợ xử lý hàng nghìn kết nối đồng thời, tối ưu hóa thuật toán chọn server. Tìm hiểu dịch vụ thuê máy chủ VPS để nâng cao hiệu suất website của bạn ngay hôm nay!

Nguyễn Trung Văn

Tôi là Nguyễn Trung Văn | Đồng sáng lập DataOnline. Với hơn 10 năm kinh nghiệm làm việc trong lĩnh vực Server, Cloud. Mục tiêu của tôi là hỗ trợ khách hàng, giúp khách hàng tiết kiệm thời gian, chi phí & tăng hiệu quả sử dụng CNTT. Với hiểu biết sâu về Network, System cũng như xu hướng của CNTT, tôi tự tin sẽ mang đến những trải nghiệm tốt cho mọi khách hàng sử dụng dịch vụ tại DataOnline. Ngoài việc tham gia vận hành Doanh nghiệp, tôi sẽ viết nhiều bài hướng dẫn nhằm tăng cường khả năng nhận thức của mọi người về CNTT.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *