Trong một dự án SEO của tôi, Yandex đã lập chỉ mục 12.500 trang. Nếu chỉ nhìn vào con số này, website có vẻ hoàn toàn ổn. Nhưng lưu lượng thực tế từ Nga lại gần như bằng 0.
Tôi cũng xây dựng dự án SEO quy mô lớn này để tiếp tục rèn kỹ năng của mình với tư cách một frontend developer.
Phản xạ đầu tiên của tôi là nghĩ theo hướng SEO. Tuy nhiên, sau khi troubleshooting, tôi tìm ra một vấn đề cơ bản hơn: đường đi của mạng. Website nằm sau Cloudflare và không thể được truy cập ổn định từ Nga. Tôi sống ở nước ngoài, vì vậy lỗi này gần như vô hình từ môi trường làm việc của tôi.
Sự cố này buộc tôi phải tách ba tín hiệu rất dễ bị đánh đồng: lập chỉ mục, khả năng truy cập và lưu lượng. Chúng không giống nhau. Một trang có thể vẫn nằm trong index trong khi người dùng thật trên một số mạng không thể tải trang đó.
Những gì tôi thực sự có thể xác nhận
Các dữ kiện trực tiếp khá đơn giản. Tôi vận hành một dự án SEO lớn phía sau Cloudflare. Yandex đã lập chỉ mục 12.500 trang, nhưng lưu lượng từ Nga gần như không có. Tôi điều tra và khoanh vùng vấn đề xuống lớp mạng. Sau đó tôi tắt hoàn toàn proxy của Cloudflare và cấu hình Nginx trên VDS của riêng mình để đảm nhiệm những phần tôi vẫn cần: cache, nén và bảo mật cơ bản.
Sau thay đổi đó, khả năng truy cập từ Nga trở lại ngay lập tức. Đây là kết luận mạnh nhất mà tôi có thể bảo vệ từ case này: thay đổi đường đi phân phối đã khôi phục reachability.
Điều không thể kết luận cũng quan trọng không kém. Case này không cho tôi biết chính xác bao nhiêu lượt truy cập đã mất, tất cả mạng nào tại Nga bị ảnh hưởng, hay lưu lượng organic sau đó phục hồi chính xác bao nhiêu. Quan sát của tôi là về khả năng truy cập và lưu lượng gần như bằng 0, chứ không phải một thí nghiệm SEO có kiểm soát.
Dữ liệu công khai chính xác hơn cách tôi giải thích ban đầu
Ban đầu tôi mô tả tình huống như thể Roskomnadzor đã chặn một số dải IP cụ thể của Cloudflare. Với bằng chứng tôi có thể hỗ trợ, cách nói đó quá cụ thể.
Ngày 26 tháng 6 năm 2025, Cloudflare công bố báo cáo của mình và cho biết kể từ ngày 9 tháng 6 năm 2025, người dùng tại Nga khi truy cập các dịch vụ được Cloudflare bảo vệ đã bị các ISP Nga throttling. Theo phân tích nội bộ của Cloudflare, ở các kết nối bị ảnh hưởng đôi khi chỉ tải được 16 KB đầu tiên của một tài nguyên web, đủ để khiến việc duyệt nhiều trang trở nên không thể sử dụng bình thường. Xem báo cáo của Cloudflare về hạn chế kết nối tại Nga.
Mô tả này phù hợp với kiểu lỗi tôi nhìn thấy, nhưng không chứng minh cơ chế thực thi chính xác tại mọi ISP và cũng không cho phép tôi quy toàn bộ mức giảm traffic trực tiếp cho Roskomnadzor. Cách diễn đạt thận trọng hơn là: đường phân phối website của tôi qua proxy Cloudflare không hoạt động ổn định từ Nga, và việc bỏ qua proxy đó đã khôi phục truy cập trong trường hợp của tôi.
Vì sao 12.500 trang đã được index không có nghĩa website khỏe
Đây là sai lầm khái niệm tôi đã đánh giá thấp. Tôi thấy 12.500 trang trong index và coi đó như dấu hiệu chung rằng website có thể truy cập được. Nhưng crawling của công cụ tìm kiếm và kết nối của người dùng cuối là hai hệ thống khác nhau.
Công cụ tìm kiếm có thể đã crawl URL từ trước, truy cập qua đường mạng khác hoặc vẫn giữ trang trong index trong khi một số người dùng không còn nhận được response đầy đủ. Vì vậy URL đã được index không chứng minh rằng người dùng của một ISP Nga cụ thể có thể mở trang hôm nay. Trong trường hợp của tôi, hai điều cùng đúng: Yandex có 12.500 trang trong index, còn lưu lượng người dùng thật từ Nga gần như bằng 0.
Indexing không phải reachability. Reachability không phải traffic.
Tôi đã thay đổi gì
- Tôi tắt hoàn toàn proxy Cloudflare. HTTP/HTTPS traffic không còn phải đi qua Cloudflare trước khi tới hạ tầng của tôi.
- Tôi chuyển các chức năng vẫn cần sang Nginx. Trên VDS của mình, tôi tự cấu hình cache, nén và các kiểm soát bảo mật cơ bản.
Điểm quan trọng không phải Nginx “tốt hơn” Cloudflare. Tôi loại bỏ một dependency mạng đã trở thành vấn đề đối với thị trường quan trọng với mình.
Truy cập trở lại, nhưng trách nhiệm vận hành cũng trở lại
Bỏ qua reverse proxy không phải là một nâng cấp miễn phí. Tài liệu hiện tại của Cloudflare giải thích rằng DNS-only đưa người dùng trực tiếp tới origin và HTTP/HTTPS traffic không còn đi qua proxy Cloudflare. Khi đó các lợi ích phụ thuộc proxy như cache và nhiều lớp bảo vệ không còn nằm phía trước origin, đồng thời IP origin có thể bị lộ. Xem tài liệu Proxy status chính thức.
Nginx có thể thay thế một phần nhu cầu của tôi như cache cục bộ, nén, xử lý request và lọc cơ bản. Nhưng nó không tự động tái tạo mạng toàn cầu của Cloudflare, khả năng DDoS được quản lý hay toàn bộ tính năng bảo mật. Vì vậy migration này là một trade-off: kiểm soát trực tiếp hơn đối với đường phân phối đổi lại trách nhiệm vận hành lớn hơn.
Với dự án này, trade-off đó đáng giá vì truy cập từ Nga là vấn đề trước mắt. Nhưng điều đó không biến VDS + Nginx thành kiến trúc an toàn nhất cho mọi trường hợp.
Nếu gặp lại vấn đề tương tự, tôi sẽ chẩn đoán thế nào
Nếu traffic sụt mạnh chỉ ở một quốc gia hoặc vùng mạng, tôi sẽ không bắt đầu bằng việc viết lại title hay content. Trước tiên tôi sẽ tách các lớp:
- Trang có tải được từ quốc gia mục tiêu và qua nhiều hơn một ISP không?
- Client có nhận toàn bộ response body, không chỉ HTTP 200 không?
- Hành vi có thay đổi khi bypass CDN hoặc reverse proxy trong một bài test có kiểm soát không?
- URL có còn được crawl và index không?
- Chỉ sau khi xác nhận reachability: impressions, clicks và sessions có thực sự thay đổi không?
Bài học thực tế là phải đo từ thị trường quan trọng. Test từ một quốc gia khác có thể cho thấy origin vẫn sống nhưng bỏ sót hoàn toàn một sự cố kết nối chỉ xảy ra theo khu vực.
Điều tôi rút ra từ sự cố này
Ban đầu nó trông giống một bí ẩn SEO: 12.500 trang đã được index nhưng gần như không có traffic Nga. Câu trả lời hữu ích lại nằm thấp hơn trong stack.
Gỡ proxy Cloudflare và dựng lại phần cần thiết bằng Nginx trên VDS của tôi đã lập tức khôi phục truy cập từ Nga. Kết quả đó tôi có thể bảo vệ bằng dữ kiện. Tôi không thể biến nó thành bằng chứng về tác động ranking của Google hay Yandex, bằng chứng về một cơ chế chặn chính xác ở cấp regulator, hay quy tắc phổ quát rằng mọi người nên bỏ Cloudflare.
Quy tắc của tôi sau case này đơn giản hơn: nếu một thị trường quan trọng, hãy đo reachability từ chính thị trường đó. Số lượng trang trong index không trả lời được liệu người dùng thật có nhận được toàn bộ trang hay không.