Hướng dẫn thiết lập máy chủ proxy ngược với Nginx từng bước một

Việc thiết lập máy chủ proxy ngược với Nginx gần như trở thành điều bắt buộc khi bạn muốn các ứng dụng web của mình an toàn hơn, có khả năng mở rộng và dễ quản lý hơn . Bạn không cần một cơ sở hạ tầng khổng lồ để hưởng lợi: ngay cả chỉ với một hoặc hai dịch vụ, bạn cũng sẽ nhận thấy sự khác biệt về hiệu suất và khả năng tổ chức.

Trong hướng dẫn này, chúng ta sẽ tìm hiểu cách Nginx hoạt động như một trung gian giữa máy khách và ứng dụng của bạn, cách nó tích hợp với Apache, .NET, Docker và các dịch vụ container hóa, những chỉ thị cấu hình nào thực sự quan trọng và cách tinh chỉnh mọi thứ trên các máy chủ Linux hiện đại như Ubuntu , bao gồm HTTPS, cân bằng tải, bộ nhớ đệm và một số tối ưu hóa bảo mật.

Nginx reverse proxy là gì và nó đóng vai trò gì trong kiến ​​trúc hệ thống của bạn?

Khi nói về Nginx, nhiều người chỉ nghĩ đến một máy chủ web dùng để phục vụ các trang tĩnh, nhưng trong nhiều năm qua, một trong những công dụng chính của nó là hoạt động như một máy chủ proxy ngược hiệu năng cao . Trong vai trò này, nó nằm phía trước một hoặc nhiều máy chủ phụ trợ (Apache, ứng dụng .NET, container Docker, Gunicorn cho Python , Node.js, v.v.) và Nginx là máy chủ nhận tất cả các yêu cầu từ máy khách.

Thay vì trình duyệt kết nối trực tiếp với ứng dụng của bạn, kết nối đó luôn được thực hiện thông qua Nginx. Từ đó, Nginx tự quyết định cách xử lý từng yêu cầu: liệu nó có thể tự phục vụ nội dung (ví dụ: các tệp tĩnh) hay nên gửi yêu cầu đó đến một máy chủ phụ trợ cụ thể để xử lý và sau đó trả về phản hồi cho máy khách.

Lớp trung gian này mang lại những lợi thế rõ rệt: nó che giấu địa chỉ IP thực của các máy chủ nội bộ, tập trung hóa việc sử dụng chứng chỉ TLS, áp dụng các quy tắc bảo mật tại một điểm duy nhất và đơn giản hóa đáng kể việc triển khai các ứng dụng mới. Hơn nữa, Nginx có thể xử lý hàng nghìn kết nối đồng thời với mức tiêu thụ tài nguyên rất thấp , lý tưởng cho các kịch bản có lưu lượng truy cập cao.

Trong các môi trường phức tạp hơn, Nginx cũng được sử dụng như một bộ cân bằng tải và cổng vào kiến ​​trúc Kubernetes, như một bộ điều khiển ingress, hoặc như một cổng API, xử lý việc định tuyến các yêu cầu đến các microservice và thực thi các chính sách như bộ nhớ đệm, giới hạn tốc độ hoặc xác thực.

Nginx xử lý các yêu cầu như thế nào khi đóng vai trò là máy chủ proxy ngược?

Khi máy khách gửi yêu cầu HTTP hoặc HTTPS đến tên miền của bạn, yêu cầu đó trước tiên sẽ đến máy chủ nơi Nginx đang chạy. Từ đó trở đi, quy trình cơ bản diễn ra như sau: Nginx phân tích URL, tiêu đề, phương thức và máy chủ.xác định vị trí khối server và khối location Điều đó sẽ quyết định xem nên làm gì với yêu cầu đó, dựa trên tiêu chí phù hợp nhất.

Nếu tài nguyên được yêu cầu là tĩnh (hình ảnh, CSS, JS, tệp tải xuống , v.v.), Nginx thường phục vụ trực tiếp từ hệ thống tệp hoặc thậm chí từ bộ nhớ đệm nội bộ của nó, giúp giảm đáng kể thời gian phản hồi và ngăn chặn các máy chủ phụ trợ lãng phí thời gian vào nội dung mà chúng không cần xử lý.

Tuy nhiên, khi yêu cầu cần logic nghiệp vụ (ví dụ: trang được tạo bởi WordPress, API .NET Core hoặc ứng dụng Jenkins), Nginx sẽ chuyển tiếp yêu cầu đó đến một trong các máy chủ phụ trợ được cấu hình bằng chỉ thị. proxy_passNó chờ phản hồi và trả lại cho máy khách như thể phản hồi đó đến trực tiếp từ Nginx.

Việc chuyển tiếp này không phải ngẫu nhiên: Nginx có thể áp dụng một số thuật toán cân bằng tải. Thuật toán đơn giản nhất là round-robin , phân phối các yêu cầu theo thứ tự trên tất cả các node. Bạn cũng có thể sử dụng least_conn (gửi yêu cầu đến máy chủ phụ có ít kết nối đang hoạt động nhất) hoặc ip_hash , giữ cho mỗi client được kết nối với cùng một máy chủ để duy trì phiên mà không cần phải chia sẻ chúng giữa các instance.

Trong môi trường nâng cao, bạn có thể tinh chỉnh mọi thứ hơn nữa bằng cách sử dụng bản đồ, biến và các mô-đun bổ sung: bạn có thể đưa ra quyết định dựa trên tiêu đề, loại nội dung, tuyến đường, tên miền hoặc thậm chí là mã tùy chỉnh mở rộng logic định tuyến . Cuối cùng, khía cạnh proxy ngược không chỉ giới hạn ở việc "chuyển tiếp lưu lượng truy cập" mà còn liên quan đến việc kiểm soát một cách thông minh cách các yêu cầu di chuyển trong cơ sở hạ tầng của bạn.

Các điều kiện tiên quyết trước khi thiết lập Nginx làm máy chủ proxy ngược

Trước khi bắt đầu chỉnh sửa cấu hình một cách tùy tiện, bạn nên đảm bảo đáp ứng một số yêu cầu cơ bản để tránh rắc rối. Tối thiểu, bạn cần một máy chủ có quyền truy cập root hoặc sudo (thường là VPS hoặc máy chủ đám mây) để cài đặt Nginx và quản lý các dịch vụ của nó.

Điều quan trọng nữa là phải có một hoặc nhiều tên miền trỏ đến địa chỉ IP công cộng Từ máy chủ Nginx. Có thể làm việc chỉ với địa chỉ IP, nhưng đối với môi trường thực tế và để SEOĐối với chứng chỉ TLS và duyệt web, người ta thường sử dụng tên miền và tên miền phụ: ví dụ, example.com, jenkins.example.com, api.example.com, Vv

Ngoài ra, bạn cần phải có sẵn các máy chủ phụ trợ nằm sau máy chủ proxy đang hoạt động: đó có thể là Apache, các ứng dụng ASP.NET Core trên cổng 5000, các dịch vụ được đóng gói bằng Docker, WordPress trên một máy chủ khác , hoặc bất kỳ thứ gì khác lắng nghe trên giao thức HTTP/HTTPS và xử lý các yêu cầu.

Ở cấp độ mạng, hãy đảm bảo rằng tường lửa hệ thống cho phép lưu lượng truy cập đến trên cổng 80 (HTTP) và 443 (HTTPS) . Trên Ubuntu với UFW, chỉ cần bật cấu hình "Nginx Full" là đủ để mở cả hai cổng mà không cần phải thiết lập các quy tắc thủ công.

Cuối cùng, việc nắm vững cú pháp cơ bản của Nginx và, nếu bạn định phục vụ nội dung được mã hóa, cần có chứng chỉ TLS hợp lệ (ví dụ: từ Let's Encrypt) cho các tên miền bạn sẽ sử dụng, để bạn có thể chấm dứt các kết nối HTTPS trong Nginx và bảo vệ lưu lượng truy cập từ phía máy khách, là rất hữu ích.

Cài đặt Nginx và cấu hình cơ bản

Trên các bản phân phối như Ubuntu, việc cài đặt Nginx thực tế chỉ cần một vài lệnh . Quy trình thông thường là trước tiên cập nhật các gói hệ thống, sau đó cài đặt máy chủ web bằng trình quản lý gói, để có được phiên bản ổn định được tích hợp tốt với systemd.

Sau khi cài đặt, Nginx sẽ khởi chạy một tiến trình nền được quản lý bởi... systemctlBạn có thể kiểm tra trạng thái, khởi động, dừng, khởi động lại hoặc cho phép nó khởi động cùng hệ thống. Mô hình dịch vụ này khiến cả Nginx và các ứng dụng phụ trợ hoạt động như một hệ thống độc lập. các tiến trình nền tự động khởi chạy sau khi khởi động lại máy.

Cấu hình chính nằm ở /etc/nginx/nginx.confNhưng trên thực tế, tập tin đó hầu như không bao giờ được sửa đổi nhiều. Nó chứa các tập tin và thư mục quan trọng khác, chẳng hạn như /etc/nginx/conf.d/ và nhị thức /etc/nginx/sites-available / /etc/nginx/sites-enabled, nơi lưu trữ các định nghĩa của các trang web ảo.

Thông thường, người ta sẽ tạo một tệp cấu hình cho mỗi tên miền hoặc dịch vụ. sites-available và sau đó kích hoạt nó bằng một liên kết tượng trưng trong sites-enabledĐiều này cho phép bạn dễ dàng kích hoạt hoặc vô hiệu hóa các trang web mà không cần xóa các tệp của chúng, và Hãy giữ cho cấu hình được sắp xếp gọn gàng ngay cả trên các máy chủ có nhiều dịch vụ khác nhau..

Trong các tập tin này, có hai khối cơ bản nổi bật. Khối server, trong đó xác định từng máy chủ ảo (tên miền, cổng, chứng chỉ, các bản ghi), và các khối location, dùng để điều khiển cách xử lý các tuyến đường cụ thể: phục vụ dữ liệu tĩnh, ủy quyền, chuyển hướng, lưu vào bộ nhớ đệm, v.v.

Cấu hình Nginx như một máy chủ proxy ngược đơn giản.

Để bắt đầu với những điều cơ bản, chỉ cần định nghĩa một khối. server nó lắng nghe trên cổng 80 cho tên miền của bạn và, bên trong, một khối location Điều này chuyển hướng tất cả lưu lượng truy cập đến máy chủ phụ trợ phù hợp. Về mặt thực tế, điều này làm cho Nginx trở nên... một điểm truy cập duy nhất vào đơn đăng ký của bạn.

Cốt lõi của cấu hình proxy dựa trên chỉ thị. proxy_passĐiều này cho biết URL nội bộ của máy chủ phụ trợ. Nó có thể trỏ đến địa chỉ IP và cổng, tên miền nội bộ hoặc một khối. upstream Điều này giúp nhóm nhiều máy chủ lại với nhau, tùy thuộc vào độ phức tạp của kiến ​​trúc hệ thống của bạn.

Cùng với proxy_pass Việc hợp tác với proxy_set_header Để bảo lưu thông tin liên quan từ yêu cầu ban đầu: máy chủ được yêu cầu, địa chỉ IP thực của máy khách hoặc giao thức (HTTP/HTTPS). Các tiêu đề này (Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Protov.v.) cho phép phần phụ trợ Ghi nhật ký lưu lượng truy cập đúng cách, tạo URL tuyệt đối nhất quán. và có thể áp dụng logic dựa trên nguồn gốc của khách hàng.

Hơn nữa, trong hầu hết mọi môi trường nghiêm túc, nên quản lý thời gian chờ của proxy bằng các chỉ thị như sau: proxy_connect_timeout, proxy_send_timeout y proxy_read_timeoutViệc điều chỉnh các thông số này giúp ngăn chặn tình trạng kết nối chậm hoặc các tiến trình kéo dài làm sập máy chủ, đặc biệt là khi bạn có các thao tác nặng hoặc các lệnh nền cần nhiều thời gian để phản hồi.

cân bằng tải và quản lý đa máy chủ

Khi ứng dụng của bạn bắt đầu phát triển hoặc bạn có nhu cầu về tính khả dụng cao, Nginx có thể hoạt động như một giải pháp. bộ cân bằng tải đặt trước nhiều máy chủ phụ trợĐể thực hiện điều này, một khối lệnh được định nghĩa. upstream Trong đó liệt kê các máy chủ sẽ thuộc nhóm máy chủ đích.

Trong khu vực đó upstream Bạn có thể thêm các chỉ thị bổ sung: trọng số để ưu tiên một số nút nhất định, thuật toán phân phối yêu cầuCác tham số keepalive được sử dụng để duy trì kết nối liên tục, v.v. Mục tiêu là phân phối lưu lượng truy cập đến một cách hiệu quả, tránh để bất kỳ máy chủ nào trở thành điểm nghẽn.

Sau khi nhóm đã được xác định, thì proxy_pass của khối server Nó trỏ đến tên của máy chủ thượng nguồn, chứ không phải một địa chỉ IP cụ thể. Từ đó, mỗi yêu cầu đến sẽ được gửi đến một trong các máy chủ phụ trợ theo chiến lược cân bằng tải đã chọn, sao cho... Việc thêm hoặc xóa một trong những nút đó chỉ liên quan đến việc sửa đổi khối phía trên.mà không cần thay đổi các cài đặt còn lại.

Cách tiếp cận này cũng tích hợp liền mạch với môi trường Docker hoặc Swarm, nơi mỗi dịch vụ hiển thị một cổng nội bộ và Nginx quản lý chúng từ bên ngoài. Cũng phổ biến khi nhóm các ứng dụng như Jenkins, GitLab, SonarQube hoặc Nexus, mỗi ứng dụng trong một container riêng, và để Nginx tập trung tất cả quyền truy cập bên ngoài từ một điểm duy nhất.

Nếu cơ sở hạ tầng của bạn được phân tán trên nhiều máy, một máy chủ proxy kiểu này cho phép bạn cô lập các dịch vụ trong các phiên bản khác nhau, với các tài nguyên chuyên dụng, trong khi vẫn cung cấp một tên miền duy nhất hoặc một tập hợp các tên miền được tổ chức tốt cho thế giới bên ngoài.

Quản lý nội dung tĩnh, bộ nhớ đệm và hiệu suất

Một trong những điểm mạnh lớn nhất của Nginx so với các máy chủ khác là hiệu quả trong việc phân phối nội dung tĩnh. Tận dụng hiệu quả điều này trong kịch bản proxy ngược đòi hỏi phải định nghĩa... bloques location cụ thể cho các tuyến đường tĩnhđể chúng không được gửi đến máy chủ phụ trợ trừ khi thực sự cần thiết.

Trong các khối này, bạn có thể chỉ định đường dẫn đến thư mục cục bộ nơi bạn lưu trữ các tệp, thêm tiêu đề hết hạn dài và bật cơ chế nén và bộ nhớ đệm. Điều này cho phép trình duyệt của người dùng giữ lại tài nguyên lâu hơn và ngăn Nginx phải tính toán lại bất cứ thứ gì mỗi khi các tệp hầu như không thay đổi được yêu cầu.

Hơn nữa, Nginx cho phép hệ thống bộ nhớ đệm nâng cao hơn ngay trong máy chủ proxy, bằng cách sử dụng các chỉ thị như... proxy_cache y proxy_cache_pathBạn có thể định nghĩa một vùng bộ nhớ đệm trên đĩa với kích thước tối đa, thời gian chờ và cấp độ thư mục để lưu trữ phản hồi, sau đó kích hoạt bộ nhớ đệm đó trong các khối proxy đến máy chủ phụ trợ của bạn.

Khi kết hợp với các hệ thống phụ trợ động (ví dụ: WordPress hoặc các ứng dụng bằng PHP, .NET hoặc Python), kết quả là các phản hồi thường xuyên nhất được phục vụ từ bộ nhớ đệm của Nginx mà không cần hệ thống phụ trợ phải tính toán lại . Điều này dẫn đến giảm tải CPU và bộ nhớ, thời gian phản hồi nhanh hơn và khả năng xử lý lưu lượng truy cập đột biến tốt hơn.

Nếu dự án của bạn bao gồm nhiều tài nguyên lặp lại, chẳng hạn như các đoạn mã HTML xuất hiện trên các trang khác nhau, bạn cũng có thể dựa vào các công cụ bên ngoài như Varnish hoặc sử dụng ESI (Edge Side Includes) kết hợp với proxy ngược để tăng tốc hơn nữa việc phân phối nội dung dạng mô-đun.

Bảo mật: Chấm dứt TLS, tường lửa và tiêu đề

Một trong những lý do chính để đặt máy chủ proxy ngược phía trước máy chủ của bạn là để tăng cường bảo mật. Bằng cách định tuyến tất cả các kết nối bên ngoài thông qua Nginx , bạn có thể tập trung hóa mã hóa, lọc và các chính sách bảo vệ tại đó mà không cần phải sao chép chúng trên từng máy chủ phụ trợ riêng lẻ.

Việc chấm dứt TLS là một ví dụ rõ ràng: chứng chỉ và khóa được cài đặt trên Nginx và được cấu hình để chấp nhận lưu lượng HTTPS trên cổng 443. Về nội bộ, bạn có thể giao tiếp với các máy chủ phụ trợ bằng HTTP thuần túy nếu muốn, giúp đơn giản hóa cấu hình của chúng. Nhưng về bên ngoài, người dùng sẽ thấy một kết nối an toàn, được mã hóa với sự hỗ trợ cho các giao thức hiện đại như TLS 1.3 và các bộ mã hóa được cập nhật.

Việc chuyển giao mã hóa cho máy chủ proxy giúp giảm tải cho các ứng dụng của bạn, vì chúng không còn cần phải đàm phán chứng chỉ hoặc thuật toán mã hóa trên mỗi kết nối. Bạn thậm chí có thể tích hợp các mô-đun hoặc phần cứng được tối ưu hóa cho SSL/TLS nếu bạn xử lý lưu lượng truy cập rất cao và muốn cải thiện hiệu suất hơn nữa.

Ngoài mã hóa, người ta thường định nghĩa... tựa đầu an toàn trong cấu hình toàn cục hoặc trong các khối cụ thể: các hạn chế của Content-Security-PolicyBảo vệ chống XSS, chặn dò tìm loại MIME, kiểm soát HSTSquy tắc của X-Frame-OptionsTrong số những điều khác. Tất cả những điều này giúp tăng cường khả năng bảo mật cho ứng dụng của bạn mà không cần phải sửa đổi mã nguồn.

Nếu bạn bổ sung thêm lớp bảo mật này bằng một tường lửa được cấu hình tốt (ví dụ: UFW trên Ubuntu) và các hệ thống bảo vệ chống lại các cuộc tấn công DDoS, chẳng hạn như giới hạn số lượng yêu cầu trên mỗi địa chỉ IP hoặc tích hợp với các dịch vụ bên ngoài, bạn sẽ có được một rào cản khá vững chắc giúp lọc các cuộc tấn công phổ biến trước khi chúng tiếp cận máy chủ ứng dụng của bạn.

Tích hợp với Docker, Gunicorn và các máy chủ ứng dụng khác.

Trong nhiều trường hợp hiện nay, các ứng dụng không chạy trực tiếp trên hệ thống máy chủ mà chạy bên trong các container hoặc phía sau các máy chủ chuyên dụng. Nginx đặc biệt phù hợp với cách tiếp cận này, vì nó không chạy bên trong container mà chỉ đơn giản là giao tiếp qua HTTP bằng cách sử dụng cổng được mỗi dịch vụ cung cấp.

Ví dụ, trong một ứng dụng Python, rất phổ biến khi máy chủ ứng dụng thực tế là Gunicorn, lắng nghe trên một cổng nội bộ (chẳng hạn như 8000) và quản lý một số tiến trình xử lý. Nginx, nằm ở phía trước, chịu trách nhiệm nhận lưu lượng truy cập công cộng, quản lý TLS, nén dữ liệu, thời gian chờ và bộ nhớ đệm, và chỉ chuyển tiếp các yêu cầu "sạch" đến Gunicorn , nơi tập trung vào việc thực thi logic ứng dụng.

Điều tương tự cũng xảy ra với các ứng dụng Java, Node.js hoặc Ruby sử dụng máy chủ ứng dụng chuyên dụng. Nginx đóng vai trò như một giao diện chung cho tất cả chúng, cho phép người dùng truy cập vào một tên miền duy nhất hoặc nhiều tên miền phụ được tổ chức tốt, trong khi bên trong, mỗi dịch vụ chạy trong môi trường riêng với ngăn xếp công nghệ phù hợp nhất với nhu cầu của nó.

Trong môi trường .NET, khi triển khai các ứng dụng ASP.NET Core trên Linux, chúng thường lắng nghe trên các cổng như 5000 hoặc 5001. Mô hình thường được tuân theo là: Khởi chạy ứng dụng như một dịch vụ hoặc tiến trình nền được quản lý bởi systemd. và cấu hình Nginx để chuyển tiếp lưu lượng truy cập từ cổng 80 hoặc 443 đến cổng nội bộ đó. Bằng cách này, người dùng chỉ cần truy cập http://localhost hoặc thuộc phạm vi công cộng và không thấy bất kỳ số cổng nào.

Khi xảy ra lỗi (ví dụ: máy chủ phụ trợ bị sập hoặc không lắng nghe trên đúng cổng), Nginx thường trả về một lỗi. Mã lỗi 502 Bad GatewayXem xét nhật ký lỗi Nginx và sử dụng các công cụ như... netstat Để kiểm tra xem cổng nào đang hoạt động, bạn có thể chẩn đoán ngay lập tức xem vấn đề nằm ở máy chủ proxy hay ứng dụng, điều này giúp quá trình chẩn đoán trở nên dễ dàng hơn nhiều.

Sử dụng Nginx với WordPress và các CMS khác thông qua máy chủ proxy ngược.

Một trường hợp sử dụng phổ biến khác là khi bạn muốn kết hợp một trang web chính không phải WordPress nhưng có blog WordPress.nhưng vẫn giữ cả hai dưới cùng một tên miền và trong một thư mục con thay vì một tên miền con. Ví dụ: có example.com được phục vụ bởi sân ga A và example.com/blog Được WordPress cung cấp trên một máy chủ khác.

Từ góc độ SEO và tổ chức nội dung, nhiều quản trị viên thích sử dụng thư mục con hơn là tên miền phụ, mặc dù về mặt kỹ thuật thì có sự khác biệt. Google tuyên bố rằng nó xử lý cả hai một cách tương tự. Một máy chủ proxy ngược với Nginx cho phép điều đó: các yêu cầu tới /blog được gửi đến máy chủ hoặc địa chỉ IP khácTrong khi đó, tên miền hiển thị cho người dùng vẫn giữ nguyên.

Để thực hiện điều này, một khối được cấu hình. location điều đó sẽ bắt giữ thư mục con được đề cập và thực hiện proxy_pass Hướng đến địa chỉ của blog được lưu trữ bên ngoài, thêm các tiêu đề thích hợp để máy chủ phụ trợ nhận ra máy khách thực và giao thức HTTPS (nếu có).

Đồng thời, trong quá trình cài đặt WordPress phía sau máy chủ proxy, URL trang web và URL trang chủ được điều chỉnh để trỏ đến tên miền chính với thư mục con, và một số biến môi trường được sửa đổi ($_SERVER['HTTP_HOST'], REQUEST_URI, v.v.) cho tránh các vòng lặp chuyển hướng hoặc các tuyến đường không nhất quán.

Bạn có thể lặp lại mô hình này nhiều lần tùy ý: cửa hàng trực tuyến trong các thư mục con, bảng điều khiển nội bộ, ứng dụng SPA, v.v., mỗi ứng dụng được lưu trữ ở bất cứ đâu bạn muốn nhưng tất cả đều được phục vụ dưới cùng một tên miền nhờ chức năng proxy ngược của Nginx.

Giám sát, ghi nhật ký và khắc phục sự cố

Một trong những lợi thế bổ sung của việc tập trung lưu lượng truy cập vào Nginx là bạn có một điểm nhìn duy nhất để quan sát những gì đang xảy ra. Máy chủ tạo ra nhật ký truy cập và lỗi trong /var/log/nginx/Chúng thu thập cả các yêu cầu đến và các lỗi xảy ra khi giao tiếp với máy chủ phụ trợ.

Nhật ký truy cập cho biết những tài nguyên nào đã được yêu cầu, từ địa chỉ IP nào, với mã trạng thái nào và mất bao lâu để được phục vụ. Từ đó, bạn có thể xác định các tuyến đường đặc biệt chậm, các lỗi lặp đi lặp lại hoặc các đỉnh lưu lượng truy cập vào những thời điểm nhất định — rất hữu ích để tinh chỉnh các quy tắc bộ nhớ đệm, giới hạn tốc độ hoặc các quyết định mở rộng quy mô.

Ngược lại, nhật ký lỗi lại rất quan trọng khi xảy ra lỗi 502, 503 hoặc các sự cố giao tiếp nội bộ khác. Chúng thường bao gồm các thông báo như "không thể kết nối với máy chủ", "hết thời gian chờ" hoặc "lỗi cú pháp trong các tệp cấu hình", giúp dễ dàng xác định lỗi mà không cần phải tìm kiếm một cách mù quáng.

Ngoài chức năng ghi nhật ký, Nginx có thể được tích hợp với các công cụ giám sát bên ngoài, cả ở cấp độ máy chủ (CPU, bộ nhớ, ổ đĩa) và tập trung vào các chỉ số HTTP (thời gian phản hồi, số lượng kết nối đang hoạt động, tỷ lệ lỗi). Điều này cung cấp cái nhìn toàn diện về hoạt động của máy chủ proxy và các dịch vụ mà nó bảo vệ , điều rất quan trọng khi quản lý các trang web hoặc ứng dụng có lưu lượng truy cập cao.

Với sự kết hợp giữa nhật ký hệ thống tốt, cảnh báo và một vài lệnh cơ bản để kiểm tra trạng thái dịch vụ, việc duy trì sự ổn định của cơ sở hạ tầng và phản ứng nhanh chóng nếu xảy ra sự cố ảnh hưởng đến tính khả dụng hoặc hiệu suất trở nên dễ dàng hơn nhiều.

Tất cả những điều trên khiến Nginx, khi được sử dụng như một máy chủ proxy ngược, trở thành một thành phần trung tâm của nhiều kiến ​​trúc hiện đại: nó cải thiện hiệu suất bằng cách phục vụ các tập tin tĩnh và bộ nhớ đệm, tăng cường bảo mật bằng cách ẩn các máy chủ phụ trợ và tập trung hóa các chính sách mã hóa, tạo điều kiện thuận lợi cho việc triển khai nhiều ứng dụng trên cùng một tên miền và cung cấp một điểm giám sát và kiểm soát duy nhất đối với lưu lượng truy cập vào và ra khỏi nền tảng của bạn.