Cloaking phía server là bộ lọc đưa ra quyết định trên server của website: request của khách đến hosting, mã PHP hỏi dịch vụ lọc xem đây là ai, và chỉ sau khi có câu trả lời mới trả offer hoặc trang trung tính cho trình duyệt. Cloaker trên trình duyệt hoạt động khác: trang đã đang tải, còn thẻ JS trong <head> ẩn nội dung, kiểm tra lượt truy cập rồi hiển thị phiên bản phù hợp.
Cả hai mô hình giải quyết cùng một việc — loại bot, scanner, công cụ spy và traffic không đúng mục tiêu — nhưng nhìn lượt truy cập từ hai phía khác nhau và hỏng theo những cách khác nhau. Cài đặt từng bước được phân tích trong bài cách kết nối cloaker với website; ở đây là kiến trúc: bên trong diễn ra gì, mỗi cách mạnh ở đâu và yếu ở đâu.
Cloaking phía server (server-side cloaking): request đi như thế nào
Đường đi của lượt truy cập trong mô hình phía server:
- Khách bấm vào quảng cáo, trình duyệt yêu cầu
website-cua-ban.com. - Request tới server của bạn, và file PHP trả lời đầu tiên chứ không phải landing.
- File gửi dữ liệu request cho dịch vụ: IP, header, tham số của link.
- Dịch vụ kiểm tra lượt truy cập và trả về quyết định.
- Server trả cho trình duyệt offer hoặc White Page. Trước thời điểm đó trình duyệt chưa nhận được một byte nào của trang.
Đặc tính then chốt — trang không tới tay khách trước khi có quyết định. Bot không có gì để lưu, trình chặn quảng cáo không có gì để cắt, mạng chậm không có gì để hiển thị sớm.
Cloaking trên trình duyệt: thẻ JS hoạt động thế nào
Trong mô hình trình duyệt, thứ tự ngược lại:
- Trình duyệt yêu cầu trang, hosting của bạn trả nó giống nhau cho tất cả.
- Dòng đầu tiên trong
<head>là thẻ — nó tải trước mọi thứ khác và ẩn trang đi. - Thẻ thu thập tín hiệu của trình duyệt và gửi cho dịch vụ.
- Có quyết định «offer» — trang được hiển thị. «White Page» hoặc không có quyết định — khách được chuyển sang trang trung tính.
Ưu điểm của mô hình này là sự đơn giản: thẻ chèn được vào bất kỳ trang nào có quyền sửa <head>, kể cả trên trình tạo website không có server riêng. Nhược điểm — HTML của landing về mặt vật lý đã nằm ở trình duyệt. Thẻ ẩn nó đi, nhưng không thể «không gửi».
Mỗi loại cloaker thấy gì về lượt truy cập
Khác biệt chính giữa hai kiến trúc là bộ tín hiệu.
| Tín hiệu | Server | Trình duyệt |
|---|---|---|
| IP, nhà cung cấp, mạng, quốc gia theo địa chỉ | Có | Có, qua dịch vụ |
| User-Agent, ngôn ngữ, referrer, header request | Có | Có |
| Tham số link: fbclid, gclid, ttclid, UTM | Có | Có |
| Client có chạy JavaScript không | Không | Có |
| Múi giờ và ngôn ngữ trình duyệt | Không | Có |
| Dấu hiệu tự động hóa (webdriver, headless) | Một phần, theo header | Có |
| Màn hình, nền tảng, thuộc tính trình duyệt | Không | Có |
| Di chuột và chạm | Không | Có |
| Thời gian ở trên trang | Không | Có |
Server thấy request, trình duyệt thấy môi trường mà request đó chạy trong. Bot đơn giản từ datacenter thì cả hai đều bắt được. Trình duyệt tự động trên proxy dân dụng với User-Agent chuẩn thì server không phân biệt được với người thật chỉ qua một request — thứ làm nó lộ là hành vi JavaScript: múi giờ không khớp với quốc gia của địa chỉ, dấu vết tự động hóa, không có thao tác. Về các dấu hiệu đó — trong bài headless browser và fingerprint và VPN, proxy và IP datacenter.
Mô hình lai: quyết định phía server cộng trang kiểm tra
Vì vậy mô hình thuần phía server trong thực tế ít gặp hơn ta tưởng. Bộ lọc phía server quyết định ngay nếu mọi thứ đã rõ qua request, còn trong trường hợp chưa chắc chắn thì trả về một trang kiểm tra ngắn: trang này chạy JavaScript, thu thập tín hiệu trình duyệt và yêu cầu quyết định lần nữa. Với người thật đó là chờ một phần giây, với bot đơn giản thì là ngõ cụt.
Ở ArtisanClo file PHP hoạt động đúng như vậy: nếu quy tắc của luồng yêu cầu JavaScript hoặc thời gian tối thiểu trên trang, khách sẽ thấy trang chờ và được kiểm tra lại. Còn khi kết nối qua bộ lọc cho Keitaro hoặc gateway cho Binom thì không có trang kiểm tra — quyết định chỉ dựa vào mạng và dấu hiệu của request, nên kiểm tra JavaScript và thời gian trên trang không có tác dụng ở đó.
Tốc độ: mili giây mất đi ở đâu
Mọi bộ lọc đều cộng thêm thời gian ra quyết định vào thời gian tải trang. Khác biệt nằm ở chỗ nào.
- Mô hình phía server thêm một request từ hosting của bạn tới dịch vụ trước khi gửi byte đầu tiên. Tốc độ phụ thuộc vào kết nối mạng của hosting: server tốt trong datacenter phản hồi nhanh, shared hosting quá tải làm chậm cả landing lẫn bước kiểm tra.
- Mô hình trình duyệt thêm việc tải script và một request từ trình duyệt của khách. Trên mạng di động điều này dễ thấy hơn, nhưng trang vẫn tải song song — sau khi có quyết định không cần tải lại.
- Trang kiểm tra chủ ý thêm thời gian chờ. Hãy bật nó ở nơi nguồn traffic thực sự đòi hỏi mức nghiêm ngặt, không phải bật mặc định ở mọi nơi.
Trong thực tế, một landing có cả chục script analytics và ảnh nặng mất nhiều thời gian hơn bất kỳ cách lọc nào. Tối ưu trang thường mang lại nhiều hơn việc chọn kiến trúc.
Độ ổn định: cloaker xử lý ra sao khi gặp sự cố
Khả năng chịu lỗi là chỗ hai kiến trúc khác nhau nhiều nhất.
Nếu thẻ JS không tải được
Thẻ là một script bên ngoài. Nếu mạng, bộ lọc của công ty hoặc trình chặn trên server không cho nó qua, trang đơn giản là không bị ẩn, và mọi người đều thấy nó, kể cả bot và công cụ spy. Sự cố ở đây là «mở». Còn nếu thẻ đã tải nhưng không có quyết định, nó chuyển khách sang White Page — đó là sự cố «đóng».
Nếu dịch vụ không trả lời server
Cách phía server chờ phản hồi trong thời gian giới hạn. Ở ArtisanClo file PHP chờ tối đa 4 giây, và khi mất kết nối thì trong một ngày phục vụ lượt truy cập theo phản hồi nhận được gần nhất: khách có mã click quảng cáo được đưa tới offer, những người còn lại tới White Page. Lượt truy cập đến trước cả phản hồi đầu tiên sẽ nhận lỗi 503. Với bộ lọc cho Keitaro và gateway cho Binom, giới hạn là 3 giây, quá thời gian đó lượt truy cập đi tới White Page.
Nếu hosting bị sập
Ở đây hai mô hình như nhau: landing nằm ở phía bạn, và bộ lọc không thể dựng lại server đã sập. Dịch vụ chịu trách nhiệm về quyết định, bạn chịu trách nhiệm về việc trang truy cập được và chứng chỉ SSL.
| Tình huống | Thẻ JS | File PHP |
|---|---|---|
| Script bị chặn dọc đường | Mọi người đều thấy trang | Không áp dụng |
| Dịch vụ không phản hồi | White Page | Chạy theo phản hồi gần nhất tới một ngày |
| Hosting không cho kết nối ra ngoài | Không ảnh hưởng | Lỗi 503, tải lâu |
| Bộ lọc bảo vệ của hosting (WAF) | Thường không ảnh hưởng | Có thể cắt request kiểm tra |
Cache, CDN và proxy: kẻ thù thầm lặng của cloaking phía server
Mô hình phía server dựa trên giả định rằng mọi request đều tới được file PHP. Có ba thứ cản trở điều này.
- Cache trang. Plugin cache, cache của hosting hoặc CDN trả về bản sao đã lưu mà không hỏi quyết định. Kết quả là mọi người thấy cùng một trang — trang đã nằm trong cache. Landing có bộ lọc cần được loại khỏi cache. Thẻ ít bị cache HTML ảnh hưởng hơn: script bên trong bản sao vẫn chạy trong trình duyệt, nếu bản sao được tạo sau khi gắn thẻ.
- Proxy phía trước website. Nếu hosting đặt proxy riêng trước server, file PHP thấy địa chỉ của proxy thay vì địa chỉ của khách, và bộ lọc đánh giá server của bạn chứ không phải người dùng. Dấu hiệu — mọi lượt truy cập trong nhật ký có cùng một IP. Cách khắc phục là chuyển tiếp địa chỉ thật (cấu hình real IP) hoặc proxy qua Cloudflare, vì file hiểu được header của Cloudflare.
- Cache quyết định trong trình duyệt. Để không hỏi dịch vụ ở mỗi lần tải lại, quyết định cho một khách có thể được lưu trong thời gian ngắn. Ở ArtisanClo với file PHP là tối đa một phút, nên sau khi sửa luồng hãy kiểm tra trong cửa sổ ẩn danh mới.
Phân tích những lỗi này và các lỗi khác — trong bài cloaker không hoạt động.
Những gì chỉ mô hình phía server làm được
Có những khả năng mà mã trong trình duyệt về mặt vật lý không làm được.
- Mã phản hồi thay cho trang. Server có thể trả 403 hoặc 404 như một địa chỉ đã đóng. Thẻ không thể đổi mã phản hồi — ở chỗ đó sẽ còn lại một trang trống.
- Chế độ shadow. Mọi khách đều đi tới offer, còn nhật ký cho thấy bộ lọc lẽ ra đã chặn ai. Đây là cách kiểm tra quy tắc mới mà không mất traffic.
- Chế độ «Tracker». Bộ lọc không chặn ai, chỉ đếm click, chuyển đổi và tiền, đồng thời đánh dấu bot trong báo cáo. Phù hợp với traffic cần thống kê chứ không cần lọc — chi tiết trong bài tracker cho affiliate.
Ở ArtisanClo chế độ shadow và chế độ «Tracker» hoạt động khi kết nối bằng file PHP, bộ lọc Keitaro hoặc gateway Binom; với thẻ JS, luồng lọc như một cloaker bình thường.
Cập nhật và bảo trì
Một khác biệt nữa mà người ta không nghĩ tới ngay — ai chịu trách nhiệm giữ mã trên website luôn mới.
- Thẻ JS được tải từ dịch vụ ở mỗi lượt truy cập. Khi dịch vụ cải thiện bước kiểm tra trình duyệt, mọi website có thẻ tự động nhận phiên bản mới — phía bạn không cần đổi gì.
- File PHP nằm trên hosting của bạn và không tự cập nhật. Logic kiểm tra và cơ sở dữ liệu bot nằm ở phía dịch vụ, nên phần việc chính của bộ lọc vẫn được cải thiện mà không cần bạn, nhưng tính năng mới của chính file thì đòi hỏi thay file. Ở ArtisanClo, việc này được báo bằng thông báo «Bạn đang chạy file cũ» kèm danh sách những gì phiên bản hiện tại của bạn chưa làm được.
Trong cả hai trường hợp, cấu hình luồng được lưu trong tài khoản chứ không phải trong mã trên website. Đổi quốc gia, mức độ nghiêm ngặt hay White Page — thay đổi có hiệu lực từ lượt truy cập tiếp theo, không cần tải lại file hay chèn lại thẻ.
Riêng về quyền truy cập cũng cần lưu ý. File PHP chạy trên server của bạn, vì vậy chỉ lấy nó từ tài khoản của dịch vụ và đừng tự sửa: một file «đã chỉnh sửa» lấy từ chat hay diễn đàn có thể làm bất cứ điều gì trên hosting của bạn.
Cloaker PHP hay thẻ JS: nên chọn gì
| Tình huống của bạn | Lựa chọn phù hợp |
|---|---|
| Trình tạo website không có quyền truy cập server | Thẻ JS |
| Hosting riêng có PHP | File PHP |
| WordPress | Plugin cài cùng cách phía server đó |
| Cần thống kê không lọc hoặc kiểm tra quy tắc ở chế độ shadow | File PHP |
| Traffic đã đi qua Keitaro hoặc Binom | Bộ lọc hoặc gateway của tracker — xem Keitaro và cloaker |
| Hosting cấm kết nối ra ngoài | Thẻ JS |
Nói ngắn gọn: thẻ cài nhanh hơn, cách phía server ổn định hơn và có nhiều chế độ hơn. Cấu hình lọc không phụ thuộc vào kiến trúc — nó được lưu trong luồng, và có thể đổi cách kết nối mà không phải sửa quy tắc. So sánh với các script tự viết, cũng thường được gọi là «cloaker PHP» — trong bài cloaker đám mây hay script tự viết.
Mẹo. Dù chọn mô hình nào, sau khi cài hãy mở link quảng cáo trong cửa sổ ẩn danh và tìm lượt truy cập của bạn trong nhật ký click. Lý do quyết định sẽ cho thấy ngay bộ lọc có thấy IP thật không, bước kiểm tra có chạy không và cache có đang trả bản sao cũ không.
Lọc phía server và chính sách của nền tảng
Kiến trúc không thay đổi khía cạnh pháp lý. Các nền tảng quảng cáo cấm cho hệ thống kiểm duyệt quảng cáo xem nội dung khác với nội dung người dùng sẽ thấy — bất kể quyết định do server hay trình duyệt đưa ra. Lợi ích chính đáng của mọi mô hình là loại bot, click tặc, công cụ spy và GEO không đúng mục tiêu, số liệu sạch và theo dõi tiền. Chi tiết hơn trong bài cloaker cho affiliate marketing.
Tóm tắt
- Cloaking phía server quyết định trước khi gửi trang: không phụ thuộc trình chặn quảng cáo, làm được mã phản hồi, chế độ shadow và chế độ «Tracker», nhưng cần PHP, kết nối ra ngoài và cẩn thận với cache và proxy.
- Cloaker trên trình duyệt đặt được vào bất kỳ
<head>nào và thấy những tín hiệu server không thấy, nhưng HTML của trang đã ở trình duyệt, và script không tải được thì không ẩn được gì. - Kết hợp ưu điểm của cả hai là quyết định phía server có trang kiểm tra: server xem mạng và request, còn đoạn JavaScript ngắn trong trình duyệt xem hành vi và môi trường.
- Điều kiện, tính năng và thành phần các gói — trên trang tính năng và bảng giá.
