Khi người dùng báo rằng:

"Website không truy cập được."

Phản xạ đầu tiên của nhiều người là kiểm tra log ứng dụng, khởi động lại service hoặc xem lại phiên bản vừa triển khai.

Tuy nhiên, những hành động này đều đang giả định rằng yêu cầu đã đến được ứng dụng.

Trong thực tế, trước khi một website có thể phản hồi, client và server phải hoàn thành nhiều bước khác nhau: phân giải tên miền, thiết lập kết nối mạng, mở kết nối TCP, khởi tạo phiên TLS và cuối cùng mới trao đổi dữ liệu HTTP.

Điều quan trọng trong quá trình xử lý sự cố không phải là thử thật nhiều lệnh, mà là xác định chính xác kết nối đang dừng ở đâu.

Bài viết này giới thiệu một quy trình chẩn đoán theo từng tầng của kết nối mạng, giúp nhanh chóng khoanh vùng phạm vi điều tra, trước khi chuyển sang kiểm tra Load Balancer, Reverse Proxy hoặc Application.

Trước khi người dùng nhận được một trang web hoặc API Response, client phải hoàn thành nhiều bước theo đúng thứ tự. Nếu một bước thất bại, toàn bộ quá trình sẽ dừng lại và các bước phía sau sẽ không được thực hiện.

Thay vì kiểm tra ngẫu nhiên, chúng ta sẽ xác minh lần lượt từng bước theo đúng quy trình thiết lập kết nối.

Các bước trên tương ứng với các tầng của mô hình OSI như sau:

Bước 1 — Kiểm tra DNS Resolution (Layer 7)

Mục tiêu Bước đầu tiên là xác nhận domain có được phân giải thành địa chỉ IP hay không.

Nếu DNS không hoạt động, client sẽ không biết cần kết nối đến máy chủ nào và toàn bộ các bước phía sau sẽ không thể thực hiện.

Kiểm tra bằng:

nslookup builder.classmethod.vn

Hoặc:

dig builder.classmethod.vn

Nếu DNS thất bại, cần kiểm tra:

• DNS Server

• DNS Record

• TTL

• Domain Configuration

Bước 2 — Kiểm tra Network Connectivity (Layer 3)

Mục tiêu Sau khi có địa chỉ IP, bước tiếp theo là xác nhận client có thể kết nối tới máy chủ hay không.

Lệnh phổ biến nhất:

ping builder.classmethod.vn

ping sử dụng giao thức ICMP để xác minh khả năng kết nối ở tầng Network.

Tuy nhiên cần lưu ý:

✅ Có thể kết nối tới máy chủ

≠

✅ Website đang hoạt động

ping không kiểm tra:

• HTTP

• HTTPS

• TLS

• Port

• Application

Nếu cần xác định request đang bị gián đoạn ở đâu trên đường truyền, sử dụng:

traceroute builder.classmethod.vn

hoặc

tracert builder.classmethod.vn

Thông qua danh sách các hop, chúng ta có thể xác định kết nối đang bị gián đoạn tại mạng nội bộ, ISP hay hạ tầng Cloud.

Bước 3 — Kiểm tra TCP Connection (Layer 4)

Mục tiêu Sau khi xác nhận có thể kết nối tới máy chủ, bước tiếp theo là kiểm tra dịch vụ có đang lắng nghe trên cổng mong muốn hay không.

Ví dụ với HTTPS:

nc -vz builder.classmethod.vn 443

Hoặc:

telnet builder.classmethod.vn 443 

Nếu kết nối TCP thất bại, nguyên nhân thường nằm ở:

• Firewall

• Security Group

• Network ACL

• Port chưa mở

• Dịch vụ chưa khởi động

Bước 4 — Kiểm tra TLS Handshake (Layer 6)

Mục tiêu Sau khi TCP được thiết lập thành công, client và server sẽ thực hiện TLS Handshake để tạo một kênh truyền được mã hóa.

Có thể kiểm tra bằng:

openssl s_client -connect builder.classmethod.vn:443

Nếu TLS thất bại, nguyên nhân thường liên quan đến:

• SSL Certificate

• Certificate Chain

• TLS Version

• Cipher Suite

Bước 5 — Kiểm tra HTTP Request / Response (Layer 7)

Mục tiêu Sau khi TLS hoàn tất, client mới có thể gửi HTTP Request đến ứng dụng.

Kiểm tra nhanh bằng:

curl -v https://builder.classmethod.vn

Một số kết quả thường gặp:

Nếu nhận được HTTP Response, có thể kết luận rằng request đã đi thành công qua toàn bộ các tầng của hạ tầng mạng và đến được service endpoint.

Nếu website vẫn gặp sự cố, lúc này mới nên chuyển sang điều tra Web Server hoặc Application.

Quy trình khoanh vùng sự cố

Thay vì chạy tất cả các công cụ cùng lúc, hãy kiểm tra theo đúng trình tự.

Mỗi bước thành công sẽ loại bỏ một nhóm nguyên nhân, trong khi mỗi bước thất bại sẽ giúp thu hẹp đáng kể phạm vi điều tra.

Lời kết

Không phải mọi sự cố "Website không truy cập được" đều xuất phát từ ứng dụng.

Việc kiểm tra theo đúng thứ tự DNS → Network → TCP → TLS → HTTP giúp xác định chính xác kết nối đang dừng ở tầng nào, từ đó rút ngắn thời gian xử lý và tránh điều tra sai hướng.

Đây là một quy trình đơn giản nhưng hiệu quả, có thể áp dụng cho hầu hết các hệ thống sử dụng HTTP hoặc HTTPS, đồng thời là nền tảng trước khi đi sâu vào phân tích Load Balancer, Reverse Proxy, Web Server hoặc Application.