Bảng điều khiển giám sát màu xanh, uptime 99.9%, nhưng hỗ trợ nhận được nhiều phàn nàn "trang web không mở được" hoặc "trang bị chặn ở khu vực của tôi". Đây không phải là lỗi của giám sát - đó là một đặc điểm kiến trúc: các bot của dịch vụ uptime kiểm tra trang web từ các IP của trung tâm dữ liệu, trong khi những người truy cập thực sự vào từ internet gia đình, mạng di động hoặc qua một nhà cung cấp cụ thể, mà bị chặn riêng biệt. Chúng ta sẽ phân tích lý do tại sao điều này xảy ra và 5 kiểm tra cần thêm vào để thấy các khối trước khi khách hàng nhận thấy.
Tại sao giám sát uptime thông thường lại lừa dối
Các dịch vụ như UptimeRobot, Pingdom, StatusCake và hầu hết các giải pháp tự lưu trữ trên Zabbix hoặc Grafana gửi yêu cầu từ các máy chủ nằm trong các trung tâm dữ liệu AWS, Hetzner, DigitalOcean và tương tự. Các máy chủ này có IP tĩnh, thuộc về ASN của nhà cung cấp dịch vụ lưu trữ - và đó là vấn đề chính. Bất kỳ hệ thống bảo vệ nào (chống gian lận Facebook, bộ lọc địa lý Wildberries, quy tắc Cloudflare, chặn ở cấp độ Roskomnadzor hoặc nhà điều hành địa phương) phân biệt lưu lượng dựa trên nguồn gốc của IP, không phải dựa trên khả năng truy cập mã HTTP.
Kết quả là một vùng mù cổ điển: bot từ IP của trung tâm dữ liệu nhận được 200 OK, vì nó không bị lọc - nó thậm chí không trông giống như "người dùng thông thường", mà hệ thống đang cố gắng chặn. Còn một người thực sự từ internet di động, Wi-Fi gia đình ở một quốc gia khác hoặc qua một nhà cung cấp cụ thể nhận được 403, chuyển hướng đến trang "không khả dụng ở khu vực của bạn" hoặc captcha vô hạn. Giám sát không thấy điều này, vì về mặt kỹ thuật trang web đang phản hồi - chỉ không phải cho người cần.
Vấn đề này rất nghiêm trọng đối với ba nhóm: những người phân tích, nơi mà các nền tảng quảng cáo và hệ thống chống gian lận chặn các landing page chính xác theo IP của nhà cung cấp; những người bán trên các thị trường, nơi nội dung và giá cả được hiển thị khác nhau tùy thuộc vào khu vực; và các chuyên gia SMM/marketing, những người thử nghiệm quảng cáo cho các quốc gia khác nhau và không nhận thấy rằng khán giả trong khu vực mục tiêu thực sự không thấy trang.
Kiểm tra 1: khối địa lý theo quốc gia và khu vực
Nguyên nhân thường gặp nhất của sự không khớp giữa báo cáo giám sát và thực tế là chặn theo địa lý IP. Trang web có thể hoàn toàn khả dụng từ Mỹ, nhưng bị chặn cho người truy cập từ Đức do yêu cầu GDPR, hoặc ngược lại - bị chặn cho các quốc gia CIS do các hạn chế trừng phạt của nền tảng quảng cáo. Bot uptime cổ điển được khởi động từ một điểm (thường là Mỹ hoặc Châu Âu) và không thể thấy những gì đang xảy ra ở các quốc gia khác.
Giải pháp là khởi động kiểm tra đồng thời từ 5-10 quốc gia bằng cách sử dụng proxy dân cư, có IP của người dùng thực tế ở khu vực cần thiết. Khác với các địa chỉ từ trung tâm dữ liệu, IP dân cư vượt qua tất cả các bộ lọc địa lý giống như người truy cập thông thường, vì vậy kết quả kiểm tra gần như chính xác với những gì khách hàng thấy.
Trên thực tế, điều này diễn ra như sau: bạn lấy danh sách các khu vực mục tiêu (ví dụ: Nga, Kazakhstan, Đức, Brazil, Ấn Độ), cấu hình script hoặc dịch vụ giám sát để luân phiên IP theo từng quốc gia và so sánh mã HTTP và nội dung trang. Nếu ít nhất một khu vực có phản hồi khác với mẫu - đó là tín hiệu về khối địa lý mà một kiểm tra uptime thông thường sẽ không bao giờ hiển thị.
Kiểm tra 2: khả năng truy cập từ các nhà mạng di động
Vùng mù thứ hai là lưu lượng di động. Nhiều nền tảng quảng cáo và hệ thống chống gian lận (đặc biệt là Facebook Ads và TikTok Ads) áp dụng các quy tắc nghiêm ngặt hơn cho các mạng di động, vì lưu lượng "sống" chủ yếu đến từ đó. Nếu landing page bị chặn bởi một nhà mạng cụ thể (MTS, Beeline, MegaFon, T-Mobile, Vodafone) do khiếu nại hoặc lọc tự động, giám sát desktop từ trung tâm dữ liệu sẽ không hiển thị điều này - ở đó không có khái niệm "nhà mạng".
Để kiểm tra này cần proxy di động, cung cấp IP từ các mạng 4G/5G thực tế của các nhà mạng. Những người phân tích sử dụng chúng không chỉ để tạo tài khoản mà còn để kiểm soát khả năng truy cập của các ưu đãi của họ chính xác trong lưu lượng di động, vì phần lớn các cú nhấp chuột vào quảng cáo trên Facebook Ads và TikTok Ads đến từ điện thoại.
Sơ đồ thực tế: thiết lập kiểm tra khả năng truy cập của landing page qua IP di động của 3-4 nhà mạng lớn nhất trong khu vực mục tiêu của bạn. Nếu mã trạng thái thay đổi thành 403 hoặc chuyển hướng chỉ trên các proxy di động trong khi phản hồi từ các trung tâm dữ liệu không thay đổi - bạn đã tìm thấy khối mà giám sát thông thường sẽ không hiển thị dưới bất kỳ cài đặt nào.
Kiểm tra 3: chặn theo nhà cung cấp internet cụ thể
Đôi khi, trang web có thể truy cập từ quốc gia nói chung, nhưng bị chặn bởi một nhà cung cấp cụ thể do lọc DNS, đưa vào danh sách hoặc quy tắc địa phương. Điều này đặc biệt đúng với Nga và CIS, nơi các khối thường được áp dụng một cách chọn lọc: một nhà mạng lọc tài nguyên, trong khi nhà mạng khác thì không. Giám sát uptime từ một IP của trung tâm dữ liệu chỉ thấy một "đường" đến trang web và không thể phát hiện sự không đồng đều như vậy.
Để đóng lại kiểm tra này, cần kiểm tra khả năng truy cập qua proxy dân cư của một số nhà cung cấp trong cùng một khu vực - ví dụ, Rostelecom, MTS, Beeline cho Nga. Nếu ít nhất một nhà cung cấp cho phản hồi từ chối, trong khi các nhà cung cấp khác mở trang bình thường - đó là một khối điểm ở cấp độ DNS hoặc IP-filter mà cần phải vượt qua riêng lẻ, không phải bằng giải pháp hàng loạt.
Đối với những người bán trên Wildberries, Ozon và Avito, điều này đặc biệt quan trọng: đôi khi thẻ sản phẩm hoặc toàn bộ tài khoản cá nhân trở nên không khả dụng chỉ cho người dùng của một nhà cung cấp do sự cố kỹ thuật từ phía thị trường, trong khi dịch vụ hỗ trợ trả lời "chúng tôi hoạt động bình thường", vì họ kiểm tra từ một kênh liên lạc khác.
Kiểm tra 4: hành vi của CDN và WAF (Cloudflare, Qrator)
Các hệ thống bảo vệ chống DDoS và các bộ lọc bot, như Cloudflare, Qrator, StormWall, sử dụng tích cực danh tiếng của địa chỉ IP để quyết định có hiển thị captcha hay chặn yêu cầu. Các dải IP từ trung tâm dữ liệu AWS, Google Cloud và DigitalOcean đã được các hệ thống này biết đến từ lâu và thường nhận được sự miễn trừ đơn giản cho các bot đáng tin cậy (bao gồm cả giám sát uptime), vì các nhà cung cấp WAF tự duy trì danh sách trắng cho các dịch vụ như vậy.
Người dùng thông thường với IP dân cư hoặc di động không có đặc quyền này và có thể gặp phải thách thức JS, captcha hoặc chặn tạm thời, nếu trên trang web có các quy tắc bảo vệ nghiêm ngặt. Điều này tạo ra một nghịch lý: càng tốt WAF hoạt động chống lại bot, thì càng tệ giám sát uptime thấy được bức tranh thực tế, mà chính nó sử dụng lưu lượng giống như bot từ các IP đáng tin cậy.
Kiểm tra ở đây rất đơn giản - gửi yêu cầu đến trang web qua proxy của trung tâm dữ liệu và qua proxy dân cư đồng thời, so sánh mã phản hồi và sự hiện diện của trang kiểm tra JS. Nếu IP của trung tâm dữ liệu nhận được 200 ngay lập tức, trong khi IP dân cư nhận được trang kiểm tra trình duyệt, điều đó có nghĩa là WAF được cấu hình sao cho người dùng thực sự mất thời gian hoặc thậm chí không thể truy cập ở bước này, mà giám sát tiêu chuẩn sẽ không bao giờ hiển thị.
Kiểm tra 5: render với fingerprint thực trong trình duyệt chống phát hiện
Kiểm tra cuối cùng và tinh tế nhất không chỉ là IP, mà là toàn bộ dấu vân tay kỹ thuật số của trình duyệt: User-Agent, độ phân giải màn hình, múi giờ, phông chữ, WebGL-render. Nhiều hệ thống chống gian lận (đặc biệt là Facebook Ads, TikTok Ads và các dịch vụ ngân hàng) quyết định về việc chặn dựa trên sự kết hợp của IP và fingerprint, không phải chỉ một tham số. Một yêu cầu HTTP đơn giản từ script giám sát không tái tạo được sự kết hợp này, do đó không thấy được các khối chỉ hoạt động trong trình duyệt với render thực tế của trang.
Để kiểm tra này cần một trình duyệt chống phát hiện hoàn chỉnh - Dolphin Anty, AdsPower, Multilogin, GoLogin hoặc Octo Browser - được cấu hình với IP dân cư hoặc di động của khu vực mục tiêu. Bạn tạo một hồ sơ với fingerprint thực tế, kết nối proxy và mở trang web như một người truy cập thông thường. Nếu trang tải bình thường qua yêu cầu HTTP thông thường, nhưng hiển thị khối hoặc chuyển hướng trong trình duyệt chống phát hiện với IP dân cư - vấn đề chính là sự kết hợp giữa fingerprint và chống gian lận, và cần phải giải quyết ở cấp độ tài khoản quảng cáo hoặc bảo vệ trang web, không phải ở cấp độ lưu trữ.
Cách thiết lập giám sát với IP dân cư và di động
Để đóng lại cả năm vùng mù, không cần phải viết mã phức tạp - chỉ cần một sơ đồ từng bước mà có thể lặp lại trong bất kỳ dịch vụ giám sát nào hoặc thậm chí thủ công khi số lượng kiểm tra không lớn.
Bước 1. Xác định danh sách các khu vực và nhà cung cấp quan trọng - thường là 3-5 quốc gia mà bạn có lưu lượng hoặc quảng cáo chính và 2-3 nhà mạng di động lớn nhất trong mỗi quốc gia.
Bước 2. Kết nối một nhóm proxy dân cư và di động với luân phiên theo các quốc gia cần thiết. Đối với giám sát tự động định kỳ, proxy dân cư với gắn kết đến thành phố hoặc nhà cung cấp cụ thể là phù hợp - điều này cho phép lặp lại kiểm tra từ cùng một điểm và thấy được động thái, không phải chỉ là một bức tranh tĩnh.
Bước 3. Cấu hình script hoặc dịch vụ sẵn có (cron-job, Zapier, giám sát tự xây dựng trên cơ sở curl hoặc requests) sao cho yêu cầu đến trang web được gửi lần lượt qua từng proxy trong nhóm, với khoảng thời gian 15-30 phút. Lưu lại mã HTTP, thời gian phản hồi và, nếu có thể, ảnh chụp màn hình của trang để kiểm tra trực quan.
Bước 4. Để kiểm tra các khối phụ thuộc vào fingerprint, thêm một lớp riêng biệt - mở trang trong trình duyệt chống phát hiện theo lịch trình, ít nhất một lần mỗi ngày cho mỗi khu vực quan trọng. Điều này có thể tự động hóa qua API tích hợp của Dolphin Anty hoặc AdsPower, cho phép khởi động hồ sơ theo lịch mà không cần sự tham gia liên tục của con người.
Bước 5. Thiết lập cảnh báo không chỉ cho mã HTTP 5xx, mà còn cho sự thay đổi nội dung trang (ví dụ: xuất hiện các từ "không khả dụng", "chặn", "khu vực bị hạn chế") và cho sự gia tăng thời gian phản hồi, điều này thường báo hiệu về thách thức JS từ WAF.
Các trường hợp thực tế: phân tích, thương mại điện tử, SMM
Một người phân tích khởi động chiến dịch trong Facebook Ads trên một landing page được lưu trữ trên VPS thông thường. Giám sát uptime tiêu chuẩn cho thấy 100% khả dụng, nhưng CTR của quảng cáo giảm mạnh ở một khu vực. Kiểm tra qua proxy di động của khu vực này cho thấy Facebook chặn lưu lượng di động trên dải IP của nhà cung cấp này - người dùng desktop thấy trang, trong khi khán giả chính từ điện thoại nhận được thông báo chặn. Giải pháp - chuyển landing page sang một dải IP khác và kiểm soát liên tục qua proxy di động của các nhà mạng mục tiêu.
Một người bán trên Wildberries thiết lập giám sát tài khoản cá nhân và thẻ sản phẩm để kịp thời nhận thấy các sự cố kỹ thuật. Một kiểm tra uptime thông thường từ trung tâm dữ liệu cho thấy trang web hoạt động, nhưng khách hàng từ một số khu vực viết rằng thẻ sản phẩm không mở được. Kiểm tra qua proxy dân cư từ các thành phố khác nhau cho thấy vấn đề nằm ở một nút CDN cụ thể, chỉ phục vụ một phần của đất nước - sau khi chuyển sang nút dự phòng, vấn đề biến mất.
Một công ty SMM đang chạy quảng cáo cho khách hàng trong TikTok Ads trên một landing page có mẫu đơn. Mẫu đơn hoạt động về mặt kỹ thuật, mã HTTP 200 ổn định với giám sát thông thường. Khi kiểm tra trong trình duyệt chống phát hiện Dolphin Anty với IP dân cư của quốc gia mục tiêu, mẫu đơn không được gửi - chống gian lận của TikTok coi đó là bot do sự không khớp của fingerprint với mẫu thiết bị mong đợi. Sau khi cấu hình các tham số hồ sơ chính xác và kiểm tra lại với IP di động thực, mẫu đơn bắt đầu nhận đơn mà không có lỗi.
Bảng: loại IP nào cho kiểm tra nào
| Loại kiểm tra | Loại IP được khuyến nghị | Điều gì được hiển thị |
|---|---|---|
| Khối địa lý theo quốc gia | Proxy dân cư | Khả năng truy cập ở khu vực cụ thể, như người dùng thực sự |
| Khối của các mạng di động | Proxy di động | Khả năng truy cập cho khán giả Facebook Ads / TikTok Ads trên điện thoại |
| Lọc bởi nhà cung cấp cụ thể | Proxy dân cư gắn với ASN của nhà cung cấp | Khối DNS điểm cho các nhà mạng riêng lẻ |
| Hành vi của CDN/WAF | So sánh IP từ trung tâm dữ liệu và IP dân cư | Sự khác biệt trong phản ứng của bảo vệ đối với lưu lượng đáng tin cậy và thông thường |
| Khối fingerprint | IP dân cư/di động + trình duyệt chống phát hiện | Phản ứng của chống gian lận với sự kết hợp giữa IP và dấu vân tay kỹ thuật số |
Danh sách kiểm tra trước khi khởi động giám sát
Trước khi coi giám sát là đáng tin cậy, hãy đi qua danh sách này:
- Kiểm tra được khởi động từ ít nhất 3-5 quốc gia của khán giả mục tiêu, không chỉ từ điểm đặt dịch vụ giám sát.
- Có một lớp kiểm tra riêng biệt qua IP di động của ít nhất hai nhà mạng trong mỗi khu vực quan trọng.
- Đã thử nghiệm khả năng truy cập qua proxy dân cư của các nhà cung cấp khác nhau trong cùng một quốc gia.
- Đã thực hiện so sánh phản hồi giữa IP từ trung tâm dữ liệu và IP dân cư để đánh giá hành vi của WAF/CDN.
- Ít nhất một lần mỗi ngày có kiểm tra qua trình duyệt chống phát hiện với fingerprint thực tế.
- Cảnh báo được thiết lập không chỉ cho mã phản hồi mà còn cho sự thay đổi nội dung và thời gian tải trang.
- Kết quả kiểm tra được ghi lại với gắn kết đến quốc gia, nhà mạng và loại IP để phân tích sau này.
Kết luận
Giám sát uptime cổ điển giải quyết một nhiệm vụ hẹp - kiểm tra xem máy chủ có phản hồi hay không. Nhưng không trả lời câu hỏi chính của doanh nghiệp: liệu người dùng thực sự từ quốc gia cần thiết, với nhà mạng cần thiết và thiết bị cần thiết có thấy chính xác những gì họ nên thấy hay không. Năm kiểm tra - theo địa lý, theo mạng di động, theo nhà cung cấp cụ thể, theo hành vi của CDN/WAF và theo fingerprint trong trình duyệt chống phát hiện - đóng lại khoảng cách này và cho thấy bức tranh gần nhất với thực tế.
Nếu bạn đang chạy quảng cáo qua Facebook Ads, TikTok Ads hoặc Google Ads, quản lý thẻ trên Wildberries và Ozon hoặc chỉ muốn thấy trang web như khách hàng thấy ở các quốc gia khác nhau, hãy thêm vào giám sát thông thường các kiểm tra qua proxy dân cư cho các bài kiểm tra địa lý và proxy di động để kiểm soát khả năng truy cập trong các mạng di động. Điều này không thay thế cho giám sát uptime tiêu chuẩn, mà đóng lại vùng mù của nó - và cho phép biết về các khối trước khi khách hàng thông báo về điều đó.