Hiểu cấu trúc tệp cấu hình và khung cấu hình Nginx
Nginx là một web server hiệu suất cao chịu trách nhiệm xử lý tải của một số trang web lớn nhất trên internet. Nó đặc biệt tốt trong việc xử lý nhiều kết nối đồng thời và vượt trội trong việc phục vụ nội dung tĩnh.Trong khi nhiều user biết về khả năng của Nginx, những user mới thường bị nhầm lẫn bởi một số quy ước mà họ tìm thấy trong các file cấu hình Nginx. Trong hướng dẫn này, ta sẽ tập trung thảo luận về cấu trúc cơ bản của file cấu hình Nginx cùng với một số hướng dẫn về cách thiết kế file của bạn.
Hiểu các bối cảnh cấu hình Nginx
Hướng dẫn này sẽ trình bày cấu trúc cơ bản được tìm thấy trong file cấu hình Nginx chính. Vị trí của file này sẽ khác nhau tùy thuộc vào cách bạn cài đặt phần mềm trên máy của bạn . Đối với nhiều bản phân phối, file sẽ được đặt tại /etc/nginx/nginx.conf . Nếu nó không tồn tại ở đó, nó cũng có thể ở /usr/local/nginx/conf/nginx.conf hoặc /usr/local/etc/nginx/nginx.conf .
Một trong những điều đầu tiên mà bạn nên chú ý khi xem file cấu hình chính là nó có vẻ được tổ chức theo cấu trúc dạng cây, được xác định bởi các bộ dấu ngoặc (trông giống như { và } ). Theo cách nói của Nginx, các khu vực mà các dấu ngoặc này xác định được gọi là “ngữ cảnh” vì chúng chứa các chi tiết cấu hình được phân tách theo khu vực quan tâm của chúng. Về cơ bản, các bộ phận này cung cấp một cơ cấu tổ chức cùng với một số logic có điều kiện để quyết định có nên áp dụng các cấu hình bên trong hay không.
Vì các ngữ cảnh có thể được xếp lớp trong nhau, nên Nginx cung cấp một mức kế thừa chỉ thị. Theo luật chung, nếu một chỉ thị hợp lệ trong nhiều phạm vi lồng nhau, một khai báo trong ngữ cảnh rộng hơn sẽ được chuyển cho bất kỳ ngữ cảnh con nào làm giá trị mặc định. Các ngữ cảnh con có thể overrides các giá trị này theo ý muốn. Cần lưu ý một overrides đối với bất kỳ chỉ thị kiểu mảng nào sẽ thay thế giá trị trước đó, không thêm vào nó.
Chỉ được dùng trong các ngữ cảnh mà chúng được thiết kế. Nginx sẽ xảy ra lỗi khi đọc file cấu hình có các lệnh được khai báo trong ngữ cảnh sai. Tài liệu Nginx chứa thông tin về ngữ cảnh mà mỗi chỉ thị có hiệu lực, vì vậy nó là một tài liệu tham khảo tuyệt vời nếu bạn không chắc chắn.
Dưới đây, ta sẽ thảo luận về các ngữ cảnh phổ biến nhất mà bạn có thể gặp phải khi làm việc với Nginx.
Bối cảnh cốt lõi
Group ngữ cảnh đầu tiên mà ta sẽ thảo luận là các ngữ cảnh cốt lõi mà Nginx sử dụng để tạo cây phân cấp và tách biệt các mối quan tâm của các đoạn cấu hình rời rạc. Đây là những bối cảnh bao gồm cấu trúc chính của cấu hình Nginx.
Bối cảnh chính
Bối cảnh chung nhất là bối cảnh "chính" hoặc " global ". Đây là ngữ cảnh duy nhất không được chứa trong các khối ngữ cảnh điển hình trông như thế này:
# The main context is here, outside any other contexts . . . context { . . . } Bất kỳ chỉ thị nào tồn tại hoàn toàn bên ngoài các khối này được cho là nằm trong bối cảnh "chính". Lưu ý nếu cấu hình Nginx của bạn được cài đặt theo kiểu module , một số file sẽ chứa các hướng dẫn dường như tồn tại bên ngoài ngữ cảnh được đặt trong ngoặc, nhưng sẽ có trong ngữ cảnh như vậy khi cấu hình được kết hợp với nhau.
Bối cảnh chính đại diện cho môi trường rộng nhất cho cấu hình Nginx. Nó được sử dụng để cấu hình các chi tiết ảnh hưởng đến toàn bộ ứng dụng ở mức cơ bản. Mặc dù các lệnh trong phần này ảnh hưởng đến các ngữ cảnh thấp hơn, nhưng nhiều lệnh trong số này không được kế thừa vì không thể overrides chúng ở các cấp thấp hơn.
Một số chi tiết phổ biến được cấu hình trong ngữ cảnh chính là user và group để chạy các quy trình công nhân, số lượng công nhân và file để lưu PID của quy trình chính. Bạn thậm chí có thể xác định những thứ như mối quan hệ của nhân viên với CPU và "sự tốt đẹp" của các quy trình của nhân viên. Tệp lỗi mặc định cho toàn bộ ứng dụng có thể được đặt ở cấp độ này (điều này có thể được overrides trong các ngữ cảnh cụ thể hơn).
Bối cảnh sự kiện
Ngữ cảnh "sự kiện" được chứa trong ngữ cảnh "chính". Nó được sử dụng để đặt các tùy chọn toàn cục ảnh hưởng đến cách Nginx xử lý các kết nối ở cấp độ chung. Chỉ có thể có một ngữ cảnh sự kiện duy nhất được xác định trong cấu hình Nginx.
Ngữ cảnh này sẽ trông giống như thế này trong file cấu hình, bên ngoài bất kỳ ngữ cảnh được đặt trong ngoặc nào khác:
# main context events { # events context . . . } Nginx sử dụng mô hình xử lý kết nối dựa trên sự kiện, do đó, các chỉ thị được xác định trong ngữ cảnh này xác định cách các quy trình công nhân sẽ xử lý các kết nối. Chủ yếu, các lệnh tìm thấy ở đây được sử dụng để chọn kỹ thuật xử lý kết nối để sử dụng hoặc để sửa đổi cách thực hiện các phương pháp này.
Thông thường, phương pháp xử lý kết nối được chọn tự động dựa trên sự lựa chọn hiệu quả nhất mà nền tảng có sẵn. Đối với hệ thống Linux, phương pháp epoll thường là lựa chọn tốt nhất.
Các mục khác có thể được cấu hình là số lượng kết nối mà mỗi nhân viên có thể xử lý, cho dù một nhân viên sẽ chỉ thực hiện một kết nối duy nhất tại một thời điểm hay nhận tất cả các kết nối đang chờ xử lý sau khi được thông báo về kết nối đang chờ xử lý và liệu nhân viên sẽ thay phiên nhau phản hồi các sự kiện .
Bối cảnh HTTP
Khi cấu hình Nginx làm web server hoặc Reverse Proxy , ngữ cảnh “http” sẽ giữ phần lớn cấu hình. Ngữ cảnh này sẽ chứa tất cả các lệnh và các ngữ cảnh khác cần thiết để xác định cách chương trình sẽ xử lý các kết nối HTTP hoặc HTTPS.
Ngữ cảnh http là anh chị em của ngữ cảnh sự kiện, vì vậy chúng nên được liệt kê cạnh nhau, thay vì lồng vào nhau. Cả hai đều là con của bối cảnh chính:
# main context events { # events context . . . } http { # http context . . . } Trong khi các ngữ cảnh thấp hơn trở nên cụ thể hơn về cách xử lý các yêu cầu, các lệnh ở cấp độ này kiểm soát các giá trị mặc định cho mọi server ảo được xác định bên trong. Một số lượng lớn các lệnh có thể được cấu hình tại ngữ cảnh này và bên dưới, tùy thuộc vào cách bạn muốn kế thừa hoạt động.
Một số các chỉ thị rằng bạn có khả năng kiểm soát cuộc gặp gỡ các vị trí mặc định để truy cập và lỗi bản ghi ( access_log và error_log ), cấu hình không đồng bộ I / O cho các hoạt động file ( aio , sendfile , và directio ), và cấu hình trạng thái của server khi lỗi xảy ra ( error_page ). Các chỉ thị khác cấu hình nén ( gzip và gzip_disable ), tinh chỉnh cài đặt giữ nguyên TCP ( keepalive_disable , keepalive_requests và keepalive_timeout ) và các luật mà Nginx sẽ tuân theo để cố gắng tối ưu hóa các gói và lệnh gọi hệ thống ( sendfile , tcp_nodelay và tcp_nopush ) . Chỉ thị bổ sung cấu hình một cấp ứng dụng root và chỉ số file tài liệu ( root và index ) và cài đặt các bảng băm khác nhau được sử dụng để lưu trữ các loại dữ liệu khác nhau ( *_hash_bucket_size và *_hash_max_size cho server_names , types , và variables ).
Bối cảnh server
Ngữ cảnh “ server ” được khai báo trong ngữ cảnh “http”. Đây là ví dụ đầu tiên của ta về các ngữ cảnh lồng nhau, trong ngoặc. Nó cũng là ngữ cảnh đầu tiên cho phép khai báo nhiều.
Định dạng chung cho ngữ cảnh server có thể trông giống như thế này. Lưu ý chúng nằm trong ngữ cảnh http:
# main context http { # http context server { # first server context } server { # second server context } } Lý do cho phép khai báo nhiều ngữ cảnh server là mỗi version xác định một server ảo cụ thể để xử lý các yêu cầu của client . Bạn có thể có bao nhiêu khối server tùy thích, mỗi khối có thể xử lý một tập hợp con các kết nối cụ thể.
Do khả năng và khả năng có nhiều khối server , loại ngữ cảnh này cũng là loại ngữ cảnh đầu tiên mà Nginx phải sử dụng thuật toán lựa chọn để đưa ra quyết định. Mỗi yêu cầu của client sẽ được xử lý theo cấu hình được xác định trong một ngữ cảnh server duy nhất, vì vậy Nginx phải quyết định ngữ cảnh server nào phù hợp nhất dựa trên chi tiết của yêu cầu. Các lệnh quyết định xem khối server có được sử dụng để trả lời một yêu cầu hay không là:
- Listen : Địa chỉ ip / kết hợp cổng mà khối server này được thiết kế để phản hồi. Nếu một khách hàng đưa ra yêu cầu trùng với các giá trị này, thì khối này có thể sẽ được chọn để xử lý kết nối.
- server_name : Chỉ thị này là thành phần khác được sử dụng để chọn một khối server để xử lý. Nếu có nhiều khối server có các lệnh lắng nghe có cùng tính chất cụ thể có thể xử lý yêu cầu, Nginx sẽ phân tích cú pháp tiêu đề “ Server lưu trữ” của yêu cầu và khớp nó với lệnh này.
Các lệnh trong ngữ cảnh này có thể overrides nhiều lệnh có thể được xác định trong ngữ cảnh http, bao gồm ghi log , root tài liệu, nén, v.v. Ngoài các lệnh được lấy từ ngữ cảnh http, ta cũng có thể cấu hình file để cố gắng phản hồi các yêu cầu ( try_files ), đưa ra các chuyển hướng và ghi lại ( return và rewrite ) và đặt các biến tùy ý ( set ).
Bối cảnh Vị trí
Bối cảnh tiếp theo mà bạn sẽ xử lý thường xuyên là bối cảnh vị trí. Bối cảnh vị trí chia sẻ nhiều chất lượng quan hệ với bối cảnh server . Ví dụ: có thể xác định nhiều bối cảnh vị trí, mỗi vị trí được sử dụng để xử lý một loại yêu cầu nhất định của khách hàng và mỗi vị trí được chọn bằng cách khớp định nghĩa vị trí với yêu cầu của khách hàng thông qua một thuật toán lựa chọn.
Trong khi các lệnh xác định xem có chọn khối server hay không được xác định trong ngữ cảnh server , thành phần quyết định khả năng xử lý yêu cầu của vị trí nằm trong định nghĩa vị trí (dòng mở khối vị trí).
Cú pháp chung trông giống như sau:
location match_modifier location_match { . . . } Các khối vị trí nằm trong bối cảnh server và không giống như các khối server , có thể được lồng vào nhau. Điều này có thể hữu ích để tạo bối cảnh vị trí chung hơn để nắm bắt một tập hợp con lưu lượng truy cập nhất định và sau đó xử lý thêm dựa trên các tiêu chí cụ thể hơn với các ngữ cảnh bổ sung bên trong:
# main context server { # server context location /match/criteria { # first location context } location /other/criteria { # second location context location nested_match { # first nested location } location other_nested { # second nested location } } } Mặc dù ngữ cảnh server được chọn dựa trên kết hợp địa chỉ / cổng IP được yêu cầu và tên server trong tiêu đề “ Server lưu trữ”, các khối vị trí phân chia thêm việc xử lý yêu cầu trong khối server bằng cách xem URI yêu cầu. URI yêu cầu là một phần của yêu cầu đến sau domain hoặc địa chỉ IP / kết hợp cổng.
Vì vậy, nếu một ứng dụng client yêu cầu http://www.example.com/blog trên cổng 80, thì http , www.example.com và cổng 80 sẽ được sử dụng để xác định khối server nào cần chọn. Sau khi server được chọn, phần /blog (URI yêu cầu), sẽ được đánh giá dựa trên các vị trí đã xác định để xác định ngữ cảnh nào sẽ được sử dụng để phản hồi yêu cầu.
Nhiều chỉ thị mà bạn có thể thấy trong ngữ cảnh vị trí cũng có sẵn ở các cấp chính. Các lệnh mới ở cấp độ này cho phép bạn tiếp cận các vị trí bên ngoài root tài liệu ( alias ), đánh dấu vị trí là chỉ có thể truy cập internal ( internal ) và proxy tới các server hoặc vị trí khác (sử dụng http, fastcgi, scgi và uwsgi proxy).
Các bối cảnh khác
Trong khi các ví dụ trên đại diện cho các ngữ cảnh thiết yếu mà bạn sẽ gặp phải với Nginx, các ngữ cảnh khác cũng tồn tại. Các ngữ cảnh bên dưới đã được tách ra vì chúng phụ thuộc vào nhiều module tùy chọn hơn, chúng chỉ được sử dụng trong một số trường hợp nhất định hoặc chúng được sử dụng cho chức năng mà hầu hết mọi người sẽ không sử dụng.
Tuy nhiên, ta sẽ không thảo luận về từng bối cảnh có sẵn. Các bối cảnh sau sẽ không được thảo luận sâu:
-
split_clients: Ngữ cảnh này được cấu hình để chia các client mà server nhận được thành các danh mục bằng cách gắn nhãn chúng với các biến dựa trên tỷ lệ phần trăm. Sau đó, chúng được dùng để thực hiện thử nghiệm A / B bằng cách cung cấp nội dung khác nhau cho các server khác nhau. -
perl / perl_set: Các ngữ cảnh này cấu hình trình xử lý Perl cho vị trí mà chúng xuất hiện. Điều này sẽ chỉ được sử dụng để xử lý với Perl. -
map: Bối cảnh này được sử dụng để đặt giá trị của một biến tùy thuộc vào giá trị của một biến khác. Nó cung cấp một ánh xạ các giá trị của một biến để xác định giá trị của biến thứ hai. -
geo: Giống như ngữ cảnh trên, ngữ cảnh này được sử dụng để chỉ định một ánh xạ. Tuy nhiên, ánh xạ này được sử dụng đặc biệt để phân loại địa chỉ IP của client . Nó đặt giá trị của một biến tùy thuộc vào địa chỉ IP kết nối. -
types: Ngữ cảnh này lại được sử dụng để lập bản đồ. Ngữ cảnh này được sử dụng để ánh xạ các loại MIME với phần mở rộng file cần được liên kết với chúng. Điều này thường được cung cấp với Nginx thông qua một file có nguồn root trong file cấu hìnhnginx.confchính. -
charset_map: Đây là một ví dụ khác về ngữ cảnh ánh xạ. Ngữ cảnh này được sử dụng để ánh xạ bảng chuyển đổi từ bộ ký tự này sang bộ ký tự khác. Trong tiêu đề ngữ cảnh, cả hai bộ đều được liệt kê và trong phần nội dung, ánh xạ diễn ra.
Các ngữ cảnh dưới đây không phổ biến như những ngữ cảnh mà ta đã thảo luận cho đến nay, nhưng vẫn rất hữu ích để biết.
Bối cảnh thượng lưu
Ngữ cảnh ngược dòng được sử dụng để xác định và cấu hình các server “ngược dòng”. Về cơ bản, ngữ cảnh này xác định một group server được đặt tên mà Nginx sau đó có thể yêu cầu proxy. Ngữ cảnh này có thể sẽ được sử dụng khi bạn đang cấu hình các loại proxy.
Bối cảnh ngược dòng phải được đặt trong ngữ cảnh http, bên ngoài bất kỳ ngữ cảnh server cụ thể nào. Hình thức chung trông giống như sau:
# main context http { # http context upstream upstream_name { # upstream context server proxy_server1; server proxy_server2; . . . } server { # server context } } Sau đó, ngữ cảnh ngược dòng có thể được tham chiếu theo tên trong khối server hoặc vị trí để chuyển các yêu cầu thuộc một loại nhất định đến group server đã được xác định. Sau đó, ngược dòng sẽ sử dụng một thuật toán (theo mặc định) để xác định server cụ thể nào sẽ gửi yêu cầu đến. Bối cảnh này cung cấp cho Nginx của ta khả năng thực hiện một số cân bằng tải khi yêu cầu ủy quyền.
Bối cảnh Thư
Mặc dù Nginx thường được sử dụng làm web hoặc server Reverse Proxy , nhưng nó cũng có thể hoạt động như một server proxy thư hiệu suất cao. Ngữ cảnh được sử dụng cho các chỉ thị kiểu này được gọi là “mail” một cách thích hợp. Ngữ cảnh thư được xác định trong ngữ cảnh “chính” hoặc “ global ” (bên ngoài ngữ cảnh http).
Chức năng chính của ngữ cảnh thư là cung cấp một khu vực để cấu hình giải pháp ủy quyền thư trên server . Nginx có khả năng chuyển hướng yêu cầu xác thực đến server xác thực bên ngoài. Sau đó, nó có thể cung cấp quyền truy cập vào server thư POP3 và IMAP để phục vụ dữ liệu thư thực tế. Ngữ cảnh thư cũng có thể được cấu hình để kết nối với SMTP Relayhost nếu muốn.
Nói chung, bối cảnh thư sẽ giống như sau:
# main context events { # events context } mail { # mail context } Bối cảnh If
Bối cảnh "nếu" có thể được cài đặt để cung cấp quá trình xử lý có điều kiện đối với các lệnh được xác định bên trong. Giống như một câu lệnh if trong lập trình thông thường, lệnh if trong Nginx sẽ thực thi các lệnh chứa nếu một thử nghiệm nhất định trả về “true”.
Ngữ cảnh if trong Nginx được cung cấp bởi module viết lại và đây là mục đích sử dụng chính của ngữ cảnh này. Vì Nginx sẽ kiểm tra các điều kiện của một yêu cầu với nhiều chỉ thị được tạo cho mục đích khác, nếu không được sử dụng cho hầu hết các hình thức thực thi có điều kiện. Đây là một lưu ý quan trọng đến nỗi cộng đồng Nginx đã tạo ra một trang có tên là if is evil .
Về cơ bản, vấn đề là thứ tự xử lý Nginx thường có thể dẫn đến các kết quả không mong muốn dường như làm mất đi ý nghĩa của một khối if. Các lệnh duy nhất được coi là an toàn tin cậy để sử dụng bên trong các ngữ cảnh này là lệnh return và rewrite (các lệnh mà ngữ cảnh này được tạo cho). Một điều nữa cần lưu ý khi sử dụng ngữ cảnh if là nó làm cho chỉ thị try_files trong cùng ngữ cảnh trở nên vô dụng.
Thông thường, một if sẽ được sử dụng để xác định xem có cần viết lại hay trả về. Những thứ này thường tồn tại trong các khối vị trí, do đó, biểu mẫu chung sẽ trông giống như sau:
# main context http { # http context server { # server context location location_match { # location context if (test_condition) { # if context } } } } Ngữ cảnh giới hạn
limit_except cảnh limit_except được sử dụng để hạn chế việc sử dụng các phương thức HTTP nhất định trong ngữ cảnh vị trí. Ví dụ: nếu chỉ một số khách hàng nhất định mới có quyền truy cập vào nội dung POST, nhưng mọi người đều có khả năng đọc nội dung, bạn có thể sử dụng khối limit_except để xác định yêu cầu này.
Ví dụ trên sẽ giống như sau:
. . . # server or location context location /restricted-write { # location context limit_except GET HEAD { # limit_except context allow 192.168.1.1/24; deny all; } } Điều này sẽ áp dụng các chỉ thị bên trong ngữ cảnh ( nghĩa là để hạn chế quyền truy cập) khi gặp bất kỳ phương thức HTTP nào ngoại trừ những phương thức được liệt kê trong tiêu đề ngữ cảnh. Kết quả của ví dụ trên là bất kỳ client nào cũng có thể sử dụng động từ GET và HEAD, nhưng chỉ những client đến từ mạng con 192.168.1.1/24 được phép sử dụng các phương thức khác.
Các luật chung cần tuân theo đối với các bối cảnh
Đến đây bạn đã có ý tưởng về các ngữ cảnh phổ biến mà bạn có thể gặp phải khi khám phá các cấu hình Nginx, ta có thể thảo luận về một số phương pháp hay nhất để sử dụng khi xử lý các ngữ cảnh Nginx.
Áp dụng chỉ thị trong bối cảnh cao nhất hiện có
Nhiều chỉ thị có hiệu lực trong nhiều ngữ cảnh. Ví dụ, có khá nhiều lệnh có thể được đặt trong ngữ cảnh http, server hoặc vị trí. Điều này cho phép ta linh hoạt trong việc cài đặt các chỉ thị này.
Tuy nhiên, theo nguyên tắc chung, tốt nhất là nên khai báo các chỉ thị trong ngữ cảnh cao nhất mà chúng có thể áp dụng và overrides chúng trong các ngữ cảnh thấp hơn nếu cần. Điều này có thể thực hiện được vì mô hình kế thừa mà Nginx triển khai. Có nhiều lý do để sử dụng chiến lược này.
Trước hết, khai báo ở mức cao cho phép bạn tránh sự lặp lại không cần thiết giữa các ngữ cảnh anh chị em. Ví dụ: trong ví dụ dưới đây, mỗi vị trí khai báo cùng một root tài liệu:
http { server { location / { root /var/www/html; . . . } location /another { root /var/www/html; . . . } } } Bạn có thể di chuyển folder root ra khối server hoặc thậm chí đến khối http, như sau:
http { root /var/www/html; server { location / { . . . } location /another { . . . } } } Thông thường, cấp độ server sẽ là thích hợp nhất, nhưng khai báo ở cấp độ cao hơn cũng có lợi thế của nó. Điều này không chỉ cho phép bạn đặt chỉ thị ở ít nơi hơn, nó còn cho phép bạn chia nhỏ giá trị mặc định xuống tất cả các phần tử con, ngăn ngừa các trường hợp bạn gặp lỗi do quên chỉ thị ở cấp thấp hơn. Đây có thể là một vấn đề lớn với các cấu hình dài. Khai báo ở các cấp cao hơn cung cấp cho bạn một mặc định lành mạnh.
Sử dụng nhiều bối cảnh anh chị em thay vì nếu logic để xử lý
Khi bạn muốn xử lý các yêu cầu khác nhau tùy thuộc vào một số thông tin có thể được tìm thấy trong yêu cầu của khách hàng, user thường chuyển đến ngữ cảnh “nếu” để cố gắng xử lý có điều kiện. Có một số vấn đề với vấn đề này mà ta đã đề cập ngắn gọn trước đó.
Đầu tiên là chỉ thị “nếu” thường trả về kết quả không phù hợp với mong đợi của administrator . Mặc dù quá trình xử lý sẽ luôn dẫn đến cùng một kết quả với cùng một đầu vào, cách mà Nginx diễn giải môi trường có thể rất khác so với những gì có thể được giả định mà không cần thử nghiệm nặng.
Lý do thứ hai cho điều này là đã có các chỉ thị được tối ưu hóa cho mục đích được sử dụng cho nhiều mục đích này. Nginx đã tham gia vào một thuật toán lựa chọn được ghi chép đầy đủ như chọn khối server và khối vị trí. Vì vậy, nếu có thể, tốt nhất là cố gắng chuyển các cấu hình khác nhau của bạn thành các khối riêng của chúng để thuật toán này có thể xử lý logic quy trình lựa chọn.
Ví dụ: thay vì dựa vào việc viết lại để đưa yêu cầu do user cung cấp sang định dạng mà bạn muốn làm việc, bạn nên cố gắng cài đặt hai khối cho yêu cầu, một khối đại diện cho phương thức mong muốn và khối kia bắt kịp các yêu cầu lộn xộn và chuyển hướng (và có thể viết lại) chúng đến đúng khối của bạn.
Kết quả thường dễ đọc hơn và cũng có thêm lợi ích là hoạt động hiệu quả hơn. Các yêu cầu đúng không phải xử lý thêm và trong nhiều trường hợp, các yêu cầu không chính xác có thể được thực hiện bằng chuyển hướng thay vì ghi lại, điều này sẽ thực thi với chi phí thấp hơn.
Kết luận
Đến đây, bạn nên nắm rõ các ngữ cảnh phổ biến nhất của Nginx và chỉ thị tạo ra các khối xác định chúng.
Luôn kiểm tra tài liệu của Nginx để biết thông tin về những ngữ cảnh nào mà một chỉ thị có thể được đặt và để đánh giá vị trí hiệu quả nhất. Cẩn thận khi tạo cấu hình của bạn sẽ không chỉ tăng khả năng bảo trì mà còn thường xuyên tăng hiệu suất.
Các tin liên quan
Cách cài đặt MoinMoin với Nginx trên Ubuntu 14.042014-11-19
Hiểu server Nginx và các thuật toán lựa chọn khối vị trí
2014-11-17
Cách thiết lập server block Nginx trên CentOS 7
2014-11-05
Cách sử dụng tệp bản đồ Salt Cloud để triển khai server ứng dụng và reverse-proxy Nginx
2014-10-27
Cách triển khai ứng dụng Rails với Passenger và Nginx trên Ubuntu 14.04
2014-10-09
Cách tạo profile AppArmor cho Nginx trên Ubuntu 14.04
2014-10-06
Cách cấu hình Nginx với SSL làm Reverse Proxy cho Jenkins
2014-09-23
Cách thiết lập nhiều trang web WordPress với Nginx trên Ubuntu 14.04
2014-08-21
Cách cài đặt và bảo mật phpMyAdmin với Nginx trên server Ubuntu 14.04
2014-08-06
Cách cài đặt và bảo mật phpMyAdmin với Nginx trên server CentOS 7
2014-08-06
