Tôi xây dựng Gitae vì liên tục gặp lại cùng một câu hỏi thực tế: website thật sự bị down, hay vấn đề chỉ nằm ở phía tôi?
Một tab trình duyệt không phải công cụ chẩn đoán tốt. Trang có thể không tải vì origin server thực sự gặp sự cố, nhưng nguyên nhân cũng có thể là DNS, chứng chỉ HTTPS, routing, firewall, port bị đóng hoặc filter, ISP, đường đi qua VPN, trạng thái trình duyệt hoặc cache local. Triệu chứng nhìn thấy giống nhau, nhưng cách xử lý đúng thì hoàn toàn khác.
Đó là vấn đề tôi muốn Gitae giải quyết: không chỉ hiện một trạng thái xanh hoặc đỏ, mà giúp thu hẹp lỗi xuống layer cần kiểm tra tiếp theo.
Vấn đề thật sự phía sau câu “website bị down”
Nhiều website checker đơn giản chỉ trả lời một câu hỏi hẹp: URL này có phản hồi từ một vị trí tại một thời điểm cụ thể hay không? Điều đó hữu ích, nhưng chưa phải là chẩn đoán outage.
Nếu DNS sai, restart application không giúp gì. Nếu HTTPS lỗi vì certificate, thay đổi nội dung trang không liên quan. Nếu một TCP port không truy cập được, server vẫn có thể đang chạy. Và nếu website mở được từ server bên ngoài nhưng không mở từ kết nối của tôi, lỗi có thể nằm ở đâu đó trên đường từ network của tôi tới đích thay vì trên application server.
Vì vậy tôi xây Gitae quanh một mô hình hữu ích hơn: website là một chuỗi dependency, và mỗi phép kiểm tra chỉ cho bằng chứng về một phần của chuỗi đó.
Góc nhìn bên ngoài, không phải lời phán quyết tuyệt đối
Các kiểm tra của Gitae chạy từ VDS server của tôi tại Moscow và Helsinki. Nhờ vậy tôi có các điểm quan sát nằm ngoài máy tính và network nơi tôi phát hiện vấn đề ban đầu.
Nếu website lỗi local nhưng vẫn phản hồi từ cả hai VDS, đó là tín hiệu quan trọng: origin ít nhất không phải không thể truy cập đối với tất cả mọi nơi. Lúc đó tôi ưu tiên xem DNS local, routing của ISP, VPN, browser, firewall hoặc vấn đề phụ thuộc vào đường mạng. Nếu remote probe cũng thất bại, có thêm cơ sở để điều tra server, DNS, certificate, routing hoặc sự cố network rộng hơn.
Tuy nhiên remote check không tự động “đáng tin cậy hơn” local check. Hai vị trí VDS không đại diện cho toàn bộ Internet. Website có thể hoạt động ở Moscow và Helsinki nhưng lỗi ở quốc gia khác, ISP khác, CDN edge khác hoặc network khác. Tôi xem kết quả remote như một điểm quan sát bổ sung, không phải kết luận toàn cầu.
Gitae hiện kiểm tra những gì
- Website check — kiểm tra URL có phản hồi từ server bên ngoài hay không.
- SSL check — kiểm tra trạng thái HTTPS/TLS certificate và các vấn đề liên quan tới certificate.
- DNS check, nslookup và dig — giúp xem domain được resolve thế nào và DNS record nào được trả về.
- Reverse DNS và IP check — hiển thị thông tin IP và dữ liệu PTR/reverse-DNS.
- Domain info và domain age — cung cấp metadata cơ bản của domain.
- Port check — thử xem target port có thể truy cập từ vị trí probe hay không.
- Find your IP — hiển thị public IP mà service nhìn thấy.
- Ping và traceroute — cung cấp network signal về latency, packet loss và đường đi tới host.
- Hosting check và CMS detection — hiển thị tín hiệu về infrastructure và technology có thể hỗ trợ nhận diện.
Tôi cố ý coi những kết quả này là signal. PTR record không chứng minh ai sở hữu server. CMS detection dựa trên public fingerprint không chứng minh chính xác software stack. Một port không truy cập được từ một probe có thể bị filter trên đường đi, chứ không nhất thiết bị đóng với tất cả mọi nơi.
Tôi diễn giải kết quả như thế nào
Giá trị thật sự xuất hiện khi kết hợp nhiều kiểm tra thay vì đọc từng kết quả riêng lẻ.
Nếu DNS trả về address tôi mong đợi, HTTPS certificate valid và website phản hồi từ cả hai VDS nhưng local vẫn không mở được, tôi sẽ điều tra đường local kỹ hơn trước khi thay đổi server. Ngược lại, nếu DNS không nhất quán hoặc remote website check cũng thất bại, có nhiều lý do hơn để kiểm tra phía infrastructure.
Ping và traceroute cũng cần được đọc cẩn thận. ICMP có thể bị filter hoặc rate-limit. Một hop không xuất hiện trong traceroute không tự động nghĩa là node đó hỏng, và host không trả lời ping vẫn có thể phục vụ HTTPS bình thường. Những tool này có giá trị vì bổ sung context, không phải vì tạo ra một kết luận cuối cùng.
Nguyên tắc chính của tôi là: một check thành công không chứng minh toàn hệ thống khỏe mạnh, và một check thất bại không tự mình giải thích nguyên nhân.
Availability và SEO không phải một khái niệm
Availability cũng quan trọng với SEO, nhưng technical outage không giống ranking problem. Crawling không phải indexing, và indexing không phải traffic.
Nếu crawler không thể tới website do DNS, network hoặc server error, tại thời điểm đó nó không thể lấy thành công nội dung bị ảnh hưởng. Google ghi rõ rằng network và DNS error khi crawling được xử lý tương tự server-side 5xx error, và tình trạng không truy cập được kéo dài có thể ảnh hưởng tới crawl cũng như các URL đã được index. Điều đó không có nghĩa mọi outage ngắn đều tự động gây thiệt hại SEO, và diagnostic tool cũng không thể chứng minh thay đổi traffic sau đó là do chính outage đó gây ra.
Với người dùng thì logic đơn giản hơn: nếu không truy cập được website, họ không thể sử dụng nó. Tùy dự án, điều đó có thể đồng nghĩa với mất session, lead, conversion hoặc revenue. Nhưng kết quả kỹ thuật không tính toán được business impact đó.
Thứ tự thực tế khi chẩn đoán website “down”
- Xác nhận triệu chứng từ network khác. Đừng coi browser local là đại diện cho toàn bộ Internet.
- Kiểm tra DNS. Xác nhận domain resolve và record trả về đúng như mong đợi.
- Kiểm tra HTTPS/TLS. Xem certificate validity và connection error.
- Kiểm tra port cần thiết. Thử khả năng truy cập từ vị trí probe.
- So sánh network signal. Dùng ping và traceroute như dữ liệu hỗ trợ.
- Xem IP, reverse DNS, hosting và CMS. Các tín hiệu này giúp xác nhận bạn đang đi tới đúng infrastructure mong đợi.
- Sau đó mới thu hẹp điều tra. Quyết định bằng chứng đang nghiêng nhiều hơn về application, server, DNS, network path hay local environment.
Đây không phải protocol incident response áp dụng cho mọi trường hợp. Với tôi, nó là cách tránh sai lầm mà Gitae sinh ra để giảm bớt: thay đổi nhầm layer chỉ vì thông tin duy nhất ban đầu là “website không mở”.
Ưu tiên giá trị sử dụng, monetization tính sau
Hiện Gitae chưa monetized. Tôi xây dựng nó trước hết cho chính mình vì muốn có cách nhanh để kiểm tra website từ bên ngoài máy của mình, rồi chuyển thẳng sang DNS, certificate, port và network diagnostics mà không phải nhảy giữa nhiều tool tách biệt.
Mục tiêu hiện tại là làm diagnostics hữu ích hơn và xem dự án có thể thu hút organic traffic qua SEO và nhu cầu thật hay không. Nếu nó đạt cả mức traffic vừa phải, tôi muốn thêm automated website monitoring với instant messenger alert. Đó là mở rộng cùng một ý tưởng từ manual diagnosis sang detection: nhận ra khi một service trở nên unavailable, rồi đưa cho owner đủ thông tin để bắt đầu điều tra nhanh.
Phần cốt lõi vẫn rất đơn giản
“Up” và “down” là triệu chứng, không phải lời giải thích.
DNS, HTTPS/TLS, routing, port, hosting, application và network của chính người dùng đều có thể tạo ra một availability problem trông rất đơn giản. Gitae không tự động tìm ra mọi root cause, và hai external server không cho biết toàn bộ Internet nhìn thấy gì. Nhưng tool có thể tập hợp nhiều signal độc lập tại một nơi.
Đó là tool tôi muốn: giúp đi từ “website không mở” tới một câu hỏi hữu ích hơn nhiều, “layer nào tôi nên kiểm tra tiếp theo?”