89,6% trang web châu Âu sử dụng CDN — Tại sao Cloudflare có thể gây nguy hiểm cho sự đơn điệu?

Ngày 7 tháng 9 năm 2026, các nhà nghiên cứu CipherCue đã công bố một khảo sát mà mọi người đi vào web tự động ở châu Âu nên đọc: trong số 44.143 công ty châu Âu mà có thể phát hiện CDN, 89,6% đang sử dụng Cloudflare. Không phải là "người dẫn đầu thị trường với khoảng cách lớn" - mà gần như toàn bộ thị trường. Đối với việc thu thập dữ liệu, đa tài khoản và bất kỳ tự động hóa nào, điều này có nghĩa là một điều đơn giản: truy cập vào chín trang web trong mười trang web ở EU được quyết định bởi cùng một thuật toán, dựa trên cùng một tiêu chí, trong cùng một giây.

Họ đã tính toán điều gì

Mẫu khảo sát - các công ty từ Đức, Vương quốc Anh, Hà Lan, Ba Lan, Pháp, Ý, Tây Ban Nha và Ireland, mà trên trang web của họ đã xác định ít nhất một thành phần CDN. Việc phát hiện được thực hiện qua các phản hồi HTTP và dấu vân tay của máy chủ: tiêu đề cf-ray và server: cloudflare cho Cloudflare, x-served-by với dấu hiệu bộ nhớ đệm cho Fastly, x-amz-cf-id cho CloudFront. Ngày quan sát - 7 tháng 9 năm 2026.

Phân bổ theo nhà cung cấp:

• Cloudflare - 39.547 công ty (89,6%)
• Amazon CloudFront - 3.112
• Fastly - 1.299
• Akamai - 396

Phân bổ theo quốc gia có sự khác biệt rõ ràng, nhưng trần ở mọi nơi đều cao:

• Hà Lan - 95,6% (7.587 trong số 7.939)
• Vương quốc Anh - 93,2% (15.846 trong số 17.007)
• Ba Lan - 92,6% (2.682 trong số 2.896)
• Pháp - 86,2% (3.456 trong số 4.008)
• Ý - 85,4% (3.126 trong số 3.661)
• Đức - 81,4% (4.650 trong số 5.715)
• Tây Ban Nha và Ireland - đều 78,8%

Các tác giả tự thừa nhận những hạn chế, và điều này là công bằng: một công ty có thể nằm dưới nhiều nhà cung cấp cùng lúc (tính toán kép), và mẫu khảo sát nghiêng về phía doanh nghiệp nhỏ và vừa - phân khúc mà gói miễn phí của Cloudflare mạnh nhất. Điều này có nghĩa là 89,6% - là tỷ lệ trong số các công ty có CDN được phát hiện, chứ không phải trong số tất cả các pháp nhân châu Âu.

Có một kiểm tra độc lập về quy mô: theo dữ liệu W3Techs vào tháng 9 năm 2026, Cloudflare được sử dụng bởi 84,7% các trang web mà có thể xác định reverse proxy - điều này tương đương với 25,2% tất cả các trang web trong chỉ mục của họ. Các phương pháp khác nhau, các mẫu khác nhau, nhưng kết luận là một: trước một phần tư web và trước phần lớn các cài đặt CDN có thể nhận diện, có một trung gian duy nhất.

Tại sao đối với tự động hóa điều này không chỉ là "một phần thị trường"

Khi có nhiều bộ lọc, một lỗi trong một dấu vân tay có thể dẫn đến việc không truy cập được vào một trang web. Khi bộ lọc thực tế chỉ có một, lỗi có thể dẫn đến việc không truy cập vào toàn bộ phân khúc ngay lập tức - và điều này thay đổi kinh tế hoạt động.

Cloudflare đưa ra yêu cầu bot score từ 1 đến 99: càng thấp, càng cao sự tự tin rằng trước trang web là tự động hóa. Mô hình tính điểm này, theo mô tả của công ty, xử lý hơn 46 triệu yêu cầu HTTP mỗi giây và xem xét không chỉ yêu cầu cụ thể của bạn mà còn cả thống kê toàn cầu trên toàn mạng: danh tiếng IP, ASN và loại địa chỉ (trung tâm dữ liệu / cư trú / di động), sự nhất quán của các tiêu đề, dấu vân tay TLS, các dấu hiệu hành vi. Việc phát hiện là đa lớp - kết hợp giữa heuristics và ML, trong đó phần lớn các quyết định dựa vào học máy.

Hệ quả thực tiễn: nhóm của bạn và dấu vân tay của bạn được đánh giá không phải bởi trang web, mà bởi mạng. Nếu bạn bị phát hiện trên một tài nguyên - tín hiệu danh tiếng đã được tính đến trong yêu cầu tiếp theo đến một tài nguyên khác. Trong một thế giới mà chín trong mười trang web châu Âu đang sử dụng mạng này, "chuyển sang mục tiêu khác và chờ đợi" không còn là một chiến lược.

IP cư trú không còn là sự miễn trừ

Logic cũ "lấy địa chỉ cư trú - qua như một người" gặp phải vấn đề rằng nhà cung cấp bộ lọc từ lâu đã phát hiện ra chính chiêu thức này. Cloudflare đã công khai mô tả một mô hình riêng để chống lại bot đi qua proxy cư trú: ban đầu họ thử nghiệm các dấu hiệu mạng (hops dư thừa, độ trễ), nhưng đã từ bỏ do các cảnh báo sai trên internet vệ tinh, và chuyển sang phân tích hành vi - các đợt hoạt động đặc trưng của các địa chỉ IP. Trong bài viết của họ, họ đã đưa ra quy mô của hiện tượng mà họ thấy: khoảng 17 triệu IP duy nhất mỗi giờ, tham gia vào các cuộc tấn công qua proxy cư trú, 45.000 ASN và 237 quốc gia và khu vực (các con số này thuộc về tháng 3 năm 2024, công ty chưa cung cấp dữ liệu mới hơn). Độ chính xác được công bố trong việc phân loại cuộc tấn công phân tán vào một trong những khách hàng - 95%, sự gia tăng phát hiện bot từ các mạng đám mây - 20%.

Chi tiết quan trọng từ đó: mô hình không được xây dựng dựa trên việc chặn IP - để không loại bỏ người dùng thực từ cùng một mạng. Đây là tin tốt cho lưu lượng truy cập hợp pháp từ các địa chỉ cư trú và tin xấu cho những ai hy vọng rằng "nhà" tự nó sẽ cho phép truy cập. Không phải loại địa chỉ quyết định, mà là sự kết hợp "loại địa chỉ + hành vi + dấu vân tay". Phân tích chi tiết sự khác biệt giữa các bức tường đã được thực hiện trong so sánh các hệ thống chống bot Cloudflare, DataDome, Akamai và Kasada - bây giờ nên trở lại với điều đó với lưu ý rằng số lượng ở dòng đầu tiên ở châu Âu đã trở nên không tương xứng nhiều.

Mặt trái: khi một cái rơi xuống - tất cả đều rơi xuống

Có một khía cạnh thứ hai của nền văn hóa đơn điệu, không phải về việc chặn mà về tính khả dụng. Một năm rưỡi qua đã cho ba sự kiện điển hình:

1. Ngày 18 tháng 11 năm 2025 - sự cố toàn cầu, ảnh hưởng đến khoảng một trong năm trang web và một phần ba trong số 10.000 trang web và dịch vụ phổ biến nhất. Nguyên nhân theo phân tích của công ty: thay đổi quyền trong cụm ClickHouse dẫn đến việc sao chép các dòng trong tệp dấu hiệu mà mô hình ML để tính điểm bot sử dụng. Thật mỉa mai: cơ chế quyết định bạn là người hay không đã làm hỏng một phần đáng kể của internet.
2. Ngày 5 tháng 12 năm 2025 - sự cố từ 8:47 UTC khoảng 25 phút, ảnh hưởng đến một tập hợp con khách hàng, mà chiếm khoảng 28% toàn bộ lưu lượng HTTP đi qua mạng.
3. Ngày 20 tháng 2 năm 2026 - vào lúc 17:48 UTC, một phần khách hàng sử dụng BYOIP (các dải IP của riêng họ), các tuyến đường đã bị thu hồi qua BGP do thay đổi trong quy trình tiếp nhận địa chỉ.

Cách diễn đạt của các tác giả nghiên cứu ở đây rất chính xác: khi một nhà cung cấp đứng trước phần lớn thị trường, những sai lầm của họ không còn là vấn đề của riêng họ mà trở thành vấn đề của tất cả mọi người cùng một lúc. Đối với quy trình thu thập dữ liệu, điều này có nghĩa là "trang web mục tiêu bị sập" và "toàn bộ khu vực bị sập" giờ đây khó phân biệt - và các cảnh báo được thiết lập cho miền cụ thể sẽ sai.

Thực hiện điều gì đó với điều này

Dưới đây là những gì thực sự thay đổi trong quy trình làm việc, nếu chấp nhận nền văn hóa đơn điệu của bộ lọc như một thực tế.

1. Kiểm tra sự kết hợp không chỉ trên một trang web. Nếu dấu vân tay của bạn vượt qua trên ba tài nguyên - bạn có thể đã kiểm tra cùng một bộ lọc ba lần. Hãy lấy một tài nguyên cho CloudFront, cho Fastly, cho Akamai và không có CDN hoàn toàn, nếu không mẫu khảo sát không chứng minh được điều gì.
2. Phân chia các nhóm theo dự án, không phải theo trang web. Vì danh tiếng được đánh giá bởi mạng, "một nhóm riêng cho mỗi miền" không cách ly được gì. Việc cách ly có ý nghĩa ở cấp độ dự án và hồ sơ: một dự án - nhóm địa chỉ riêng, bộ dấu vân tay riêng, nhịp độ riêng.
3. Xem xét loại và nguồn gốc địa chỉ. ASN và loại địa chỉ - là cách trực tiếp vào việc tính điểm. Đối với các mục tiêu nhạy cảm, các proxy cư trú và địa chỉ di động là hợp lý; các nhiệm vụ kỹ thuật hàng loạt (kiểm tra khả dụng, API của riêng bạn, làm việc với các nền tảng không có chống bot mạnh) thì tốt hơn và hợp lý hơn khi sử dụng proxy trung tâm dữ liệu, không lãng phí lưu lượng truy cập đắt đỏ.
4. Đừng đốt subnet. Các mô hình hành vi phát hiện các đợt hoạt động trên địa chỉ. Nhịp độ đều trên một nhóm rộng sẽ được đánh giá tốt hơn so với một đợt tấn công ngắn và mạnh từ một nhóm hẹp.
5. Đưa dấu vân tay vào trật tự hoàn toàn. Dấu vân tay TLS, thứ tự và thành phần của các tiêu đề, phiên bản HTTP, hành vi JS - được đánh giá cùng nhau. IP cư trú với dấu vân tay của một khách hàng HTTP trần sẽ cho kết quả tồi tệ hơn so với địa chỉ trung tâm dữ liệu gọn gàng với ngăn xếp trình duyệt hợp pháp.
6. Phân biệt "chúng tôi bị chặn" và "họ gặp sự cố". Quy tắc đơn giản: khi có sự gia tăng lớn về lỗi, trước tiên hãy kiểm tra xem có phải tất cả các mục tiêu không liên quan đều bị sập cùng một lúc và trang trạng thái của nhà cung cấp cho thấy điều gì. Retry trong thời gian xảy ra sự cố toàn cầu - là cách để đốt cháy nhóm mà không lý do.
7. Có kế hoạch B cho ngày mà bộ lọc sẽ sập. Một hàng đợi nhiệm vụ có khả năng chờ đợi và hoàn thành những gì đã bị bỏ lỡ, tốn kém hơn trong phát triển, nhưng có thể chịu đựng 25 phút không khả dụng mà không mất dữ liệu.

Kết luận

Số liệu 89,6% - không phải về việc Cloudflare xấu, và không phải về việc web châu Âu đã đóng cửa. Nó nói về việc đa dạng mục tiêu không còn có nghĩa là đa dạng trở ngại. Một hệ thống tính điểm, một mô hình, một cơ sở danh tiếng - và, do đó, một chế độ từ chối chung: cả khi bạn bị coi là bot, và khi nhà cung cấp tự mình làm rơi các tuyến đường.

Kết luận cho thực tiễn có phần nhàm chán, nhưng hữu ích: ngừng tối ưu hóa việc vượt qua "theo trang web" và bắt đầu tối ưu hóa hành vi - chất lượng địa chỉ, nhịp độ đều, dấu vân tay nhất quán, chẩn đoán lỗi hợp pháp. Đây là điều duy nhất hoạt động tốt cả ở phía bên kia 89,6% và ở phía này.