Website được thiết kế tối ưu cho thành viên chính thức. Hãy Đăng nhập hoặc Đăng ký để truy cập đầy đủ nội dung và chức năng. Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "CNTT" các nội dung bạn quan tâm.

Bài 1. Reverse Proxy là gì và vì sao bắt buộc phải có trong hệ thống nhiều website, nhiều web app

ICT

1. Reverse Proxy là gì?

Reverse Proxy là một máy chủ trung gian đứng phía trước các máy chủ web/backend, tiếp nhận toàn bộ kết nối từ client (Internet hoặc mạng ngoài), sau đó chuyển tiếp (proxy) các yêu cầu đó về các máy chủ phía sau theo các quy tắc đã được cấu hình.

Khác với Forward Proxy (proxy phía client), Reverse Proxy:

  • Không phục vụ cho một nhóm người dùng cụ thể,

  • Mà phục vụ cho toàn bộ hệ thống backend,

  • client không biết phía sau Reverse Proxy có bao nhiêu máy chủ, chạy công nghệ gì, hay đặt ở đâu.

Về mặt logic, Reverse Proxy trở thành:

  • “Cổng vào duy nhất” của hệ thống web,

  • Điểm kiểm soát lưu lượng,

  • Điểm kết thúc HTTPS,

  • Và là lớp bảo vệ đầu tiên cho các máy chủ backend.

Trong mô hình chuẩn, client chỉ nhìn thấy Reverse Proxy, còn các máy chủ web và web application phía sau hoạt động trong mạng riêng (private network).


2. Điều gì xảy ra khi KHÔNG sử dụng Reverse Proxy?

Trong các hệ thống nhỏ, mỗi website hoặc web app thường được triển khai theo cách:

  • Mỗi server có IP public riêng,

  • NAT port trực tiếp từ modem/router vào từng máy chủ,

  • Mỗi máy chủ tự xử lý HTTPS, bảo mật, logging.

Cách làm này có thể chấp nhận được khi:

  • Chỉ có 1–2 website,

  • Lưu lượng thấp,

  • Không yêu cầu cao về bảo mật và dự phòng.

Tuy nhiên, khi hệ thống phát triển lên hàng chục hoặc hàng trăm website và web application, mô hình này nhanh chóng bộc lộ các vấn đề nghiêm trọng:

  1. Không kiểm soát được bề mặt tấn công

    • Mỗi backend lộ trực tiếp ra Internet.

    • Khó đồng bộ firewall, HTTPS, chính sách bảo mật.

  2. Quản lý HTTPS trở nên hỗn loạn

    • Mỗi server tự cấp chứng chỉ.

    • Gia hạn SSL phân tán, dễ lỗi, dễ quên.

  3. Không thể mở rộng linh hoạt

    • Thêm website đồng nghĩa với thêm NAT, thêm IP public.

    • Phụ thuộc hạ tầng mạng và nhà cung cấp Internet.

  4. Khó xử lý sự cố

    • Khi một backend lỗi, client truy cập trực tiếp và nhận lỗi.

    • Không có lớp trung gian để chuyển hướng hoặc cô lập sự cố.

  5. Không phù hợp môi trường vận hành lâu dài

    • Đặc biệt trong môi trường bệnh viện, đơn vị nhà nước, nơi hệ thống phải ổn định và dễ kiểm soát.


3. Reverse Proxy giải quyết những vấn đề gì?

Việc đưa Reverse Proxy vào kiến trúc giúp giải quyết đồng thời nhiều bài toán cốt lõi.

3.1. Tập trung điểm truy cập – một cổng vào duy nhất

Toàn bộ lưu lượng từ Internet chỉ đi qua:

  • IP của Reverse Proxy,

  • Port 80/443.

Điều này cho phép:

  • Kiểm soát truy cập tập trung,

  • Giảm tối đa việc expose backend ra ngoài,

  • Đơn giản hóa cấu hình mạng và firewall.

3.2. Quản lý HTTPS tập trung

Reverse Proxy đảm nhiệm:

  • SSL termination,

  • Gia hạn chứng chỉ,

  • Chính sách HTTPS thống nhất.

Backend phía sau:

  • Có thể chạy HTTP thuần trong mạng riêng,

  • Không cần quan tâm đến SSL, CA, chứng chỉ.

Với hàng trăm website, lợi ích này là bắt buộc, không phải tùy chọn.

3.3. Tách lớp rõ ràng giữa Internet và hệ thống nội bộ

Reverse Proxy tạo ra ranh giới rõ ràng:

  • Phía ngoài: Internet, client, Cloudflare.

  • Phía trong: hệ thống web, web app, database, AI.

Nhờ đó:

  • Backend không cần IP public,

  • Dễ áp dụng chính sách “zero trust” ở mức cơ bản,

  • Giảm rủi ro tấn công trực tiếp.

3.4. Linh hoạt trong phân phối lưu lượng

Reverse Proxy cho phép:

  • Định tuyến theo domain, subdomain, path,

  • Chuyển backend mà không thay đổi phía client.

Trong hệ thống có QMS server chính và AI server dự phòng, điều này đặc biệt quan trọng:

  • Khi QMS gặp sự cố, chỉ cần thay đổi cấu hình proxy,

  • Client vẫn truy cập domain cũ, không bị gián đoạn về mặt địa chỉ.


4. Reverse Proxy trong hệ thống nhiều website, nhiều web app

Trong hệ thống có:

  • Hàng trăm website độc lập,

  • Hàng trăm web application điều hành nội bộ,

Reverse Proxy không chỉ là “một thành phần”, mà là xương sống của kiến trúc web.

Các vai trò chính bao gồm:

  • Phân phối truy cập theo domain/subdomain,

  • Chuẩn hóa cấu hình timeout, upload, header,

  • Ghi log tập trung để phân tích sự cố,

  • Hạn chế tác động dây chuyền khi một web app lỗi.

Không có Reverse Proxy, hệ thống:

  • Rất khó mở rộng,

  • Rất khó kiểm soát,

  • Và gần như không thể vận hành bền vững.


5. Vì sao Reverse Proxy là “bắt buộc”, không phải “nên có”?

Trong bối cảnh hệ thống được mô tả trong tài liệu này, Reverse Proxy là yêu cầu bắt buộc vì các lý do sau:

  1. Quy mô lớn

    • Số lượng website và web app nhiều.

  2. Yêu cầu bảo mật cao

    • Dữ liệu y tế, dữ liệu quản trị.

  3. Cần dự phòng và khôi phục nhanh

    • Không chấp nhận downtime kéo dài.

  4. Hạ tầng backend mạnh, nội bộ

    • Không cần expose trực tiếp ra Internet.

  5. Vận hành dài hạn

    • Cấu hình phải rõ ràng, dễ kiểm soát, dễ chuyển giao.

Reverse Proxy trong trường hợp này không phải là “tối ưu hóa”, mà là điều kiện cần để hệ thống tồn tại và phát triển ổn định.


Tóm lại

Reverse Proxy là lớp trung gian đóng vai trò:

  • Cổng vào duy nhất,

  • Lớp bảo vệ,

  • Bộ điều phối truy cập,

  • Và nền tảng cho khả năng mở rộng và dự phòng.

Trong các phần tiếp theo, tài liệu sẽ đi sâu vào:

  • Kiến trúc cụ thể của hệ thống Reverse Proxy,

  • Cách thiết kế mạng, IP,

  • Và các quyết định kỹ thuật quan trọng để triển khai Reverse Proxy hiệu quả trên Debian 12.