Kiểm tra Port 80/443, UFW và Cloud Firewall: Đừng cài xong SSL rồi quên mở khóa cổng rào

Phạm vi thực hành: Hệ điều hành Ubuntu 24.04 LTS trên VPS độc lập; tên miền lab sử dụng là lab-cf02.localhost.vn. Bạn chỉ nên thực hiện thay đổi trên hạ tầng thuộc quyền quản lý của mình. Phần số liệu thực nghiệm trong bài tách bạch rõ đợt kiểm tra listener/UFW/curl ngày 30/09/2026 với ảnh chụp màn hình console và quan sát giao diện Cloud Firewall ngày 01/10 (chỉ đọc trạng thái, không sửa đổi rule). Ngoài ra, mục bổ sung ở cuối bài ghi nhận thêm đợt thực nghiệm từ máy trạm Windows và kiểm tra HTTPS/IPv6 trên máy chủ LAB03 vào ngày 05/10/2026.

Trong giới quản trị hệ thống có một pha tự hủy kinh điển: hì hục cấu hình SSL/TLS cho NGINX xong xuôi, kiểm tra cú pháp báo ok hết cả, nhưng mở trình duyệt gõ https:// thì vòng tròn tải trang cứ quay đều đến lúc văng lỗi Connection Timed Out. Ngồi đập đầu vào file cấu hình NGINX suốt 2 tiếng đồng hồ mới sực nhớ ra… quên chưa mở Port 443 trên Cloud Firewall hoặc UFW! Ngược lại, cũng có những bạn vừa thuê VPS về đã vội vàng bấm nút “Allow HTTPS” trên tường lửa rồi thắc mắc sao web chưa tự có ổ khóa xanh. Hãy nhớ: tường lửa chỉ là bác bảo vệ gác cổng cho phép xe đi qua, còn bên trong nhà phải có tiến trình NGINX đang mở cửa lắng nghe (listener) ở đúng cổng đó thì cuộc giao tiếp mới thành công.

Xác định rõ hệ thống của bạn đang ở chặng nào

Về nguyên lý chuẩn: cổng TCP 80 phục vụ giao thức HTTP không mã hóa, còn cổng TCP 443 phục vụ giao thức HTTPS có mã hóa SSL/TLS. Nếu bạn mới hoàn thành bài cài đặt NGINX cơ bản và dựng Virtual Host tĩnh ở bước trước, việc trên máy chủ chỉ mới có cổng 80 hoạt động là hoàn toàn bình thường; cổng 443 sẽ chỉ xuất hiện sau khi bạn xin cấp chứng chỉ SSL và khai báo chỉ thị listen 443 ssl;. Vì vậy, nếu chưa cấu hình TLS mà gõ https:// thấy báo lỗi từ chối kết nối, hãy ghi chú rõ là “chưa bật HTTPS trên NGINX” chứ đừng vội đổ oan cho tường lửa chặn cổng.

Trước khi đụng chạm vào bất kỳ quy tắc tường lửa nào, hãy chuẩn bị sẵn địa chỉ IP công khai của đúng chiếc VPS đang làm việc, giữ nguyên một cửa sổ kết nối SSH đang mở (đừng đóng nó cho tới khi thử mở thêm được một cửa sổ SSH thứ hai thành công!), đồng thời kiểm tra trước đường vào bảng điều khiển cứu hộ (VNC/Web Console) của nhà cung cấp. Đặc biệt lưu ý: trên các nền tảng đám mây, một nhóm Cloud Firewall (Security Group) có thể đang được gắn chung cho nhiều VPS cùng lúc, nên trước khi xóa hay sửa rule, bạn hãy nhìn kỹ xem nhóm đó đang áp dụng cho những máy chủ nào.

Sơ đồ 4 mắt xích bắt buộc để một gói tin từ trình duyệt người dùng chạm tới được dịch vụ web trên VPS do đội ngũ localhost.vn biên soạn.

Bước 1: Soi tiến trình đang lắng nghe (Listener) ngay bên trong máy chủ

sudo ss -ltnp '( sport = :80 or sport = :443 )'
systemctl is-active nginx
sudo nginx -t

Khi đọc bảng kết quả từ lệnh ss -ltnp, bạn cần chú ý cả cột địa chỉ IP lắng nghe (Local Address:Port) lẫn tên tiến trình sở hữu ở cột cuối. Nếu thấy 127.0.0.1:80, nghĩa là dịch vụ đó chỉ chịu nói chuyện nội bộ bên trong máy chủ (loopback) chứ khách ngoài Internet gọi vào sẽ bị từ chối thẳng thừng; ngược lại, 0.0.0.0:80 cho biết NGINX đang mở rộng cửa đón mọi kết nối IPv4 trên tất cả các giao diện mạng. Đối với dòng [::]:443, đây là socket lắng nghe trên nền IPv6 (tùy cấu hình nhân Linux mà nó có thể kiêm luôn cả IPv4 hoặc chỉ thuần IPv6, nên cách chắc ăn nhất vẫn là kiểm tra thực tế từng giao thức).

Nếu nhìn vào danh sách ss mà hoàn toàn vắng bóng cổng :443, bạn có mở toang cả UFW lẫn Cloud Firewall thì HTTPS cũng không thể nào sống dậy được. Lúc này hãy quay vào kiểm tra file cấu hình Server Block TLS, đường dẫn file chứng chỉ và đọc file error.log của NGINX. Trong trường hợp hiếm gặp khi thấy cổng 80 hoặc 443 đã có mặt nhưng tên tiến trình bên cạnh lại là apache2 hay một dịch vụ lạ hoắc nào đó, hãy bình tĩnh xác minh xem ai đã cài đặt nó trước khi ra lệnh tắt dịch vụ.

Đợt chụp màn hình console thực tế lúc 13:08:06 (giờ Việt Nam) ngày 01/10/2026 dưới đây ghi nhận dịch vụ NGINX 1.24.0 đang ở trạng thái active/enabled, kiểm tra cú pháp đạt chuẩn và đang lắng nghe tại 0.0.0.0:80 cùng [::]:80. Truy vấn HTTP qua loopback trả về mã 200, kích thước 615 byte với tiêu đề trang Welcome. Lưu ý bộ lọc lệnh trong lần chụp này chỉ truy vấn riêng cổng 80 để minh họa bước khởi đầu:

Ảnh chụp console thực tế lúc 13:08:06 (giờ Việt Nam) ngày 01/10/2026. Vùng hiển thị kết quả lệnh được giữ nguyên vẹn từng pixel và chỉ bổ sung thanh logo localhost.vn ở dưới chân ảnh. Bấm vào ảnh để xem kích thước gốc.

Bước 2: Tự gọi thử HTTP/TLS ngay tại máy chủ gốc (Origin)

curl -I http://127.0.0.1/
curl -I --resolve lab-cf02.localhost.vn:80:127.0.0.1 \
  http://lab-cf02.localhost.vn/

Khi máy chủ của bạn đã cấu hình xong chứng chỉ SSL/TLS trên cổng 443, hãy kiểm tra thêm bằng lệnh:

curl -I --resolve lab-cf02.localhost.vn:443:127.0.0.1 \
  https://lab-cf02.localhost.vn/

Tại sao chúng ta không gõ luôn curl -I https://127.0.0.1/ cho nhanh mà phải dùng cờ --resolve dài dòng? Bởi vì chứng chỉ SSL của Let’s Encrypt được cấp cho tên miền lab-cf02.localhost.vn chứ không phải cấp cho con số 127.0.0.1! Việc giữ đúng tên miền trong URL kết hợp với --resolve giúp curl gửi chuẩn xác cả Host header lẫn thông tin SNI (Server Name Indication) trong quá trình bắt tay TLS. Đồng thời, chúng tôi khuyên bạn không nên lạm dụng cờ -k (--insecure) khi nghiệm thu, vì cờ này bảo curl nhắm mắt bỏ qua mọi lỗi chứng chỉ giả mạo hay hết hạn, làm che khuất mất những lỗi cấu hình nghiêm trọng mà người dùng thật trên trình duyệt sẽ gặp phải.

Quy tắc suy luận ở bước này cực kỳ rõ ràng: nếu đứng ngay trên VPS gọi 127.0.0.1 mà đã báo lỗi từ chối kết nối hoặc lỗi chứng chỉ TLS, thì nguyên nhân nằm 100% ở cấu hình NGINX/SSL bên trong máy — đừng mất công đi sửa tường lửa. Ngược lại, nếu gọi nội bộ tại VPS trả về 200 OK ngọt lành mà lấy laptop bên ngoài gọi vào lại bị Timeout, lúc đó chắc chắn bức tường chắn đang nằm ở UFW, Cloud Firewall hoặc đường truyền mạng.

Bước 3: Đọc kỹ bảng quy tắc UFW trước khi thêm hoặc xóa rule

sudo ufw status verbose
sudo ufw status numbered

Khi thấy trạng thái UFW là Status: active, hãy nhìn xuống danh sách bên dưới xem đã có dòng cho phép (ALLOW IN) đối với cổng 80/tcp và 443/tcp hay chưa. Đối với một máy chủ web công khai tiêu chuẩn, bạn có thể mở hai cánh cửa này bằng cặp lệnh ngắn gọn:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Lời khuyên sống còn từ các đàn anh từng bị nhốt ngoài cửa server: hãy nâng niu quy tắc cho phép cổng SSH hiện tại như trứng mỏng và tuyệt đối không gõ ufw reset chỉ để “làm sạch cài lại từ đầu” khi đang kết nối từ xa. Nếu UFW trên máy bạn đang ở trạng thái inactive (tắt) và bạn muốn bật nó lên, hãy đảm bảo bạn đã chạy lệnh cho phép đúng cổng SSH trước tiên, sau đó mở thử một cửa sổ Terminal thứ hai đăng nhập thành công rồi mới yên tâm làm việc tiếp.

Thêm một lưu ý tinh tế cho các môi trường staging/lab nội bộ: đôi khi bạn chỉ muốn mở cổng 80/443 cho duy nhất địa chỉ IP văn phòng của mình truy cập. Cách làm này rất bảo mật, nhưng hãy nhớ rằng nếu bạn dùng Let’s Encrypt với phương thức xác thực HTTP-01, các máy chủ kiểm định của Let’s Encrypt từ nhiều nơi trên thế giới sẽ cần gọi vào cổng 80 của bạn để xác minh quyền sở hữu tên miền mỗi khi cấp mới hoặc gia hạn chứng chỉ. Vì vậy, đừng khóa cứng cổng 80 theo một IP cố định nếu bạn đang dùng cơ chế gia hạn tự động qua HTTP-01.

Sơ đồ nguyên tắc mở cổng tối thiểu cho máy chủ WordPress: mở 80/443 cho web, giữ vững cổng SSH và đóng kín cổng cơ sở dữ liệu 3306.

Ảnh chụp toàn trang (GoFullPage) lúc 13:54:16 (giờ Việt Nam) ngày 01/10/2026 ghi nhận kết quả kiểm tra trực tiếp lúc 13:50:46: UFW đang bật (active), chính sách mặc định chặn chiều vào (deny incoming), mở các cổng TCP 22/80/443 cho cả IPv4 lẫn IPv6. Bên dưới là danh sách listener thực tế với MariaDB chỉ lắng nghe nội bộ tại 127.0.0.1:3306. Bấm vào ảnh để xem rõ từng dòng lệnh.

Bước 4: Kiểm tra lớp áo giáp ngoài cùng — Cloud Firewall của nhà cung cấp

Nếu UFW là chiếc khóa cửa gắn ngay trên cánh cửa gỗ nhà bạn, thì Cloud Firewall (tường lửa đám mây trên bảng điều khiển của nhà cung cấp VPS) chính là trạm gác bảo vệ ở cổng khu đô thị. Gói tin từ Internet muốn vào tới UFW thì trước hết phải vượt qua được trạm gác Cloud Firewall này. Hãy đăng nhập vào bảng điều khiển quản trị VPS, đối chiếu chính xác tên máy chủ, địa chỉ IP và mã định danh (Instance ID), sau đó kiểm tra các quy tắc chiều vào (Inbound Rules) đối với giao thức TCP cổng 80 và 443 trên cả IPv4 lẫn IPv6.

Cụ thể trên giao diện quản trị của CloudFly mà chúng tôi thực nghiệm, đường dẫn truy cập là: Public Cloud → Instances → chọn đúng máy chủ → tab Cloud Firewall. Bạn hãy luôn đối chiếu kỹ tên máy localhost-tutorial-lab-02 cùng địa chỉ IP 103.82.26.183 trước khi đọc bảng quy tắc, và đừng quên kiểm tra xem nhóm tường lửa đó có đang được gắn chung cho các máy chủ nào khác trong tài khoản hay không.

Vào lúc 16:38–16:39 (giờ Việt Nam) ngày 01/10/2026, kết quả trích xuất trực tiếp từ tab Cloud Firewall của máy chủ LAB-CF-02 ghi nhận trạng thái nhóm mặc định như sau:

Cần lưu ý rõ: cấu hình cho phép toàn bộ cổng ở bảng trên là trạng thái mặc định sẵn có của nhóm Firewall trên môi trường lab để nhường quyền kiểm soát chi tiết cho UFW bên trong máy chủ, chứ không phải là khuyến nghị bảo mật bảo bạn phải mở toang mọi cổng ở mọi nơi. Tài liệu Hướng dẫn cấu hình và quản lý Cloud Firewall tại CloudFly (xuất bản ngày 30/06/2023, đối chiếu lại ngày 01/10/2026) cũng mô tả rõ cơ chế nhóm mặc định này. Nhờ việc giữ UFW hoạt động chặt chẽ ở Bước 3, dù Cloud Firewall bên ngoài có mở rộng thì các cổng nội bộ trên máy chủ vẫn được bảo vệ an toàn.

Hãy luôn khắc cốt ghi tâm: UFW và Cloud Firewall hoạt động độc lập theo cơ chế nối tiếp (AND). Chỉ cần một trong hai anh bảo vệ này lắc đầu chặn lại, gói tin sẽ không bao giờ chạm tới được NGINX. Ngoài ra, nếu bạn bật đám mây cam (Proxy) trên Cloudflare, người dùng thực chất đang kết nối tới máy chủ biên (Edge) của Cloudflare, rồi Cloudflare mới gọi về IP gốc của bạn. Nếu bạn thiết lập tường lửa trên VPS chỉ cho phép dải IP của Cloudflare đi vào (Origin Pull), thì việc bạn ngồi ở nhà dùng curl gọi thẳng vào IP gốc bị từ chối lại là dấu hiệu cho thấy tường lửa đang làm việc… quá chuẩn!

Bước 5: Kiểm tra thực tế từ mạng bên ngoài và đọc vị các mã lỗi

curl -I --connect-timeout 10 http://lab-cf02.localhost.vn/
curl -I --connect-timeout 10 https://lab-cf02.localhost.vn/

Từ chiếc máy tính cá nhân của bạn (hoặc một mạng khác bên ngoài VPS), hãy chạy hai lệnh curl với cờ giới hạn thời gian chờ --connect-timeout 10 như trên. Nếu bạn dùng Windows PowerShell, lệnh Test-NetConnection lab-cf02.localhost.vn -Port 443 cũng là một công cụ cực kỳ lợi hại để kiểm tra xem kết nối TCP tới cổng 443 có thông hay không (nhưng nhớ rằng kết nối TCP thành công mới chỉ nói lên cổng đã mở, bạn vẫn phải dùng curl hoặc trình duyệt để kiểm tra chứng chỉ SSL và nội dung HTTP).

Bảng chẩn đoán nhanh ở trên chính là tấm bản đồ giúp bạn không bao giờ đi lạc hướng: gặp lỗi 404 hay 502 thì tuyệt đối đừng tốn thời gian vào sửa Cloud Firewall, vì gói tin đã đi xuyên qua tường lửa vào tận phòng khách của NGINX rồi mới nhận được mã lỗi HTTP đó!

Sơ đồ phân biệt nhanh 4 nhóm triệu chứng lỗi kết nối phổ biến do đội ngũ localhost.vn biên soạn.

Quy trình hoàn tác (Rollback) an toàn và câu hỏi thường gặp

Nếu bạn lỡ tay thêm nhầm một quy tắc vào UFW và muốn xóa nó đi, hãy luôn chạy lại lệnh sudo ufw status numbered ngay trước mỗi lần xóa để nhìn rõ số thứ tự mới nhất (bởi mỗi khi bạn xóa một dòng, các dòng phía dưới sẽ tự động đôn số thứ tự lên!). Đối với Cloud Firewall, hãy khôi phục lại đúng thông số rule đã chụp lưu trước khi sửa. Và nhớ quy tắc vàng: luôn giữ cửa sổ SSH hiện tại mở nguyên cho tới khi bạn bật một cửa sổ mới và đăng nhập thử thành công.

Hỏi: Tôi cài WordPress thì có cần mở cổng 3306 trên UFW và Cloud Firewall không?
Đáp: Tuyệt đối không! Khi mã nguồn PHP của WordPress và hệ quản trị cơ sở dữ liệu MariaDB nằm chung trên một chiếc VPS, chúng trò chuyện nội bộ với nhau qua Unix socket hoặc địa chỉ loopback 127.0.0.1 cực nhanh và an toàn. Trình duyệt của khách truy cập chỉ nói chuyện với NGINX qua cổng 80/443 chứ không bao giờ kết nối trực tiếp vào database của bạn.

Hỏi: Thấy cổng 443 đã mở thông suốt có đồng nghĩa với việc HTTPS của website đã an toàn tuyệt đối chưa?
Đáp: Chưa hẳn! Cổng 443 mở mới chỉ đảm bảo đường ống vận chuyển đã thông. Để HTTPS thực sự an toàn và không bị trình duyệt cảnh báo đỏ, bạn còn phải đảm bảo chứng chỉ SSL khớp đúng tên miền, chuỗi chứng chỉ trung gian (Fullchain) đầy đủ, còn thời hạn hiệu lực và trên trang không bị lỗi nội dung hỗn hợp (Mixed Content).

Hỏi: Lúc web bị lỗi không vào được, có nên tắt phăng cả UFW lẫn Cloud Firewall đi để thử cho lẹ không?
Đáp: Không nên tập thói quen đó trên môi trường thực tế. Việc tắt toàn bộ tường lửa vừa làm phơi bày các dịch vụ nội bộ ra Internet trong lúc bạn đang loay hoay sửa lỗi, vừa dễ khiến bạn quên bật lại sau khi sửa xong. Chỉ mất 30 giây chạy ss -ltnp và ufw status là bạn đã nhìn thấu từng lớp mà không cần dỡ bỏ hàng rào bảo vệ.

Kết quả thực nghiệm trên máy chủ LAB-CF-02 ngày 30/09/2026

Trong đợt kiểm tra tổng thể web stack lúc 22:48 (UTC+7) ngày 30/09/2026, máy chủ LAB-CF-02 ghi nhận dịch vụ NGINX ở trạng thái active, kiểm tra nginx -t đạt chuẩn, và mở đầy đủ các listener tại 0.0.0.0:80, 0.0.0.0:443 cùng [::]:80. Tường lửa UFW ở trạng thái active, chặn toàn bộ chiều vào mặc định và chỉ cho phép các cổng TCP 22/80/443 trên cả IPv4 lẫn IPv6.

Khi chạy curl nội bộ kèm cờ --resolve cho tên miền lab, kết quả trả về mã chuyển hướng HTTP 301 → HTTPS, và tiếp theo là HTTPS 200 OK. Đợt chạy curl từ máy trạm bên ngoài VPS lúc 22:51 (UTC+7) cũng nhận về chuẩn xác chuỗi 301 → 200 OK với chứng chỉ TLS hợp lệ mà hoàn toàn không cần dùng cờ -k.

Thực nghiệm bổ sung trên LAB03: Kiểm tra HTTPS từ Windows và IPv6 ngày 05/10/2026

Để cung cấp thêm góc nhìn thực tế từ máy khách Windows và mạng IPv6, vào ngày 05/10/2026 chúng tôi đã thực hiện thêm một đợt đo đạc độc lập giữa máy trạm Windows Server 2022 (103.179.173.134) và máy chủ Ubuntu LAB03 (103.166.185.141). Một tên miền thử nghiệm riêng biệt là lab-net03.localhost.vn được trỏ bản ghi A (chế độ DNS-only, TTL 300) về LAB03 để phục vụ trang HTML kiểm tra kết nối mạng mà không làm xáo trộn hệ thống WordPress chính.

Vào lúc 10:38 (giờ Việt Nam), công cụ Certbot đã xin cấp thành công chứng chỉ SSL miễn phí từ Let’s Encrypt cho tên miền lab-net03.localhost.vn (hạn dùng đến ngày 03/01/2027). Dịch vụ NGINX trên LAB03 vượt qua bài kiểm tra cú pháp và mở đầy đủ các cổng lắng nghe TCP 80/443 trên cả hai họ giao thức IPv4 và IPv6. Khi kiểm tra từ bên ngoài qua IPv4 103.166.185.141, truy vấn HTTP tự động chuyển hướng 301 sang HTTPS và trả về mã 200 OK cùng kết quả xác thực chứng chỉ hoàn hảo (ssl_verify_result=0).

Ngay sau đó, từ cửa sổ PowerShell trên máy trạm Windows, chúng tôi thực thi hai câu lệnh kiểm tra nối tiếp:

Test-NetConnection lab-net03.localhost.vn -Port 443
curl.exe -I https://lab-net03.localhost.vn/
$LASTEXITCODE

Vào lúc 10:45–10:46 (giờ Việt Nam), lệnh Test-NetConnection trả về thông số rõ ràng: RemoteAddress=103.166.185.141, RemotePort=443, SourceAddress=103.179.173.134 và TcpTestSucceeded=True. Tiếp nối ngay phía dưới, lệnh curl.exe trên Windows nhận về phản hồi HTTP/1.1 200 OK, Server: nginx/1.24.0 (Ubuntu), Content-Type: text/html, Content-Length: 686 cùng mã thoát bằng 0. Như vậy, cả tầng giao vận TCP lẫn tầng ứng dụng HTTPS đều được xác nhận thông suốt từ môi trường Windows.

Lúc 10:47 (giờ Việt Nam), trình duyệt Chromium mở trang https://lab-net03.localhost.vn hiển thị chính xác chuỗi định danh localhost-network03-261005 với mã HTTP 200, giao thức bảo mật TLS 1.3, tổ chức cấp phát WE1 (Google Trust Services / Let’s Encrypt) khớp đúng tên miền. Bố cục trang hiển thị chuẩn xác trên cả khung nhìn máy tính 1440 px lẫn khung nhìn di động 390 px:

Hai ảnh chụp màn hình trình duyệt thực tế trên môi trường LAB03 ngày 05/10/2026 ở độ phân giải 1440 px và 390 px (giữ nguyên vẹn pixel vùng trang web và chỉ đính kèm thanh logo localhost.vn ở chân ảnh).

Ghi chú thú vị về đường truyền IPv6 của máy điều khiển: Mặc dù bản thân máy chủ LAB03 tự gọi HTTP qua địa chỉ IPv6 của chính nó trả về mã 200 ngon lành, nhưng khi chúng tôi đứng từ máy điều khiển gọi trực tiếp sang IPv6 của LAB03 thì lại vấp phải mã lỗi kết nối số 7 của curl (không định tuyến được tới mạng đích từ nhánh mạng của máy điều khiển). Đây là tình huống rất thực tế ngoài đời: máy của bạn chưa có đường truyền IPv6 chuẩn ra quốc tế thì không thể tự làm trọng tài chấm điểm IPv6 cho VPS được! Đó là lý do chúng ta cần tới một trọng tài quốc tế độc lập ở bước tiếp theo.

Kiểm định HTTPS qua IPv6 từ bên ngoài bằng công cụ quốc tế Internet.nl

Vào lúc 11:05 (giờ Việt Nam) ngày 05/10/2026, chúng tôi thêm bản ghi AAAA (chế độ DNS-only, TTL 300) cho tên miền lab-net03.localhost.vn trỏ về địa chỉ IPv6 2001:df7:c600:11:f816:3eff:feda:6212 của máy chủ LAB03. Ngay sau khi xác nhận Resolver của Cloudflare đã phân giải đúng cả bản ghi A lẫn AAAA, chúng tôi sử dụng hệ thống kiểm định tiêu chuẩn mở Internet.nl để đo kiểm từ bên ngoài.

Đợt kiểm định hoàn tất vào lúc 04:06 UTC (tức 11:06 giờ Việt Nam). Bạn có thể xem trực tiếp báo cáo lưu trữ công khai trên Internet.nl của hostname lab-net03: hệ thống xác nhận máy chủ web IPv6 hoàn toàn truy cập được từ Internet, nội dung trả về giữa IPv4 và IPv6 đồng nhất, và hạng mục HTTPS available = yes đạt chuẩn xanh trên cả địa chỉ IPv4 103.166.185.141 lẫn địa chỉ IPv6 2001:df7:c600:11:f816:3eff:feda:6212, kèm theo chuỗi tin cậy chứng chỉ (Trust Chain) hợp lệ.

Ảnh chụp trực tiếp báo cáo Internet.nl lúc 11:08 (giờ Việt Nam) ngày 05/10/2026 xác nhận kết nối HTTPS hoạt động tốt trên cả IPv4 và IPv6 của LAB03.

Tất nhiên, vì đây là một cấu hình NGINX cơ bản vừa mới bật SSL để kiểm tra thông cổng nên báo cáo chi tiết của Internet.nl cũng chỉ ra rất minh bạch các hạng mục nâng cao chưa bật như: chưa thêm header HSTS, thứ tự ưu tiên bộ mã hóa (cipher suites) còn ở mức mặc định và tên miền chưa bật DNSSEC. Ngoài ra, ở mục định tuyến hạ tầng mạng RPKI, hai dải mạng 103.166.184.0/23 và 2001:df7:c600::/48 (thuộc mã hiệu mạng tự trị ASN135905) hiện trạng thái not-found do nhà mạng chưa công bố bản ghi ROA tương ứng — đây là thông số thuộc tầng định tuyến BGP của nhà cung cấp hạ tầng chứ không phải lỗi cấu hình UFW trên VPS của bạn. Sau khi hoàn tất đợt đo kiểm, toàn bộ phiên đăng nhập Windows, cấu hình Virtual Host tạm, chứng chỉ ACME và hai bản ghi DNS lab-net03 đều đã được thu dọn sạch sẽ.

Tài liệu tham khảo và bước tiếp theo

Các số liệu thực nghiệm trong bài được ghi nhận qua ba mốc ngày 30/09, 01/10 và 05/10/2026, phân định rạch ròi theo từng máy chủ lab. Các tài liệu kỹ thuật chính thống được đối chiếu bao gồm: Certbot Documentation: Using Certbot (webroot & configuration) (đối chiếu ngày 05/10/2026), Ubuntu Server Docs: Firewalls (UFW) (đối chiếu ngày 01/10/2026), cùng NGINX Docs: How nginx processes a request và Let’s Encrypt Docs: Challenge Types (đối chiếu ngày 30/09/2026).

Mời bạn xem lại bức tranh toàn cảnh tại lộ trình cài đặt WordPress trên VPS từ A đến Z, hoặc xem lại bài trước: Cấu hình Virtual Host cho domain và www. Tiếp theo, hãy cùng sang Bài 35: Domain chưa trỏ đúng: Quy trình kiểm tra từ Registrar tới Web Server để nắm trọn bộ kỹ năng bắt bệnh tên miền tổng hợp.