Một rò rỉ WebRTC hoặc DNS không được chú ý có thể làm mất trắng nhiều tháng làm việc với tài khoản chỉ trong một lần đăng nhập. Các nền tảng như Facebook, TikTok và Instagram đã học được cách đối chiếu IP "được khai báo" của proxy với IP thực tế bị rò rỉ qua trình duyệt. Trong bài viết này là danh sách kiểm tra cụ thể gồm 7 kiểm tra cần thực hiện trước khi mở hồ sơ mới, chứ không phải sau khi bị cấm.
Rò rỉ WebRTC và DNS là gì và tại sao chúng làm hỏng hồ sơ
Khi bạn khởi động hồ sơ trong trình duyệt chống phát hiện và kết nối với proxy, bạn mong đợi rằng trang web chỉ thấy IP của proxy. Trong thực tế, trình duyệt đồng thời sử dụng hai cơ chế có thể tiết lộ IP thực của bạn: WebRTC (công nghệ cho cuộc gọi video và kết nối P2P) và các yêu cầu DNS (chuyển đổi tên miền thành địa chỉ IP). Nếu các kênh này không được che giấu, nền tảng nhận được hai địa chỉ khác nhau cho một hồ sơ — đây là một tín hiệu cổ điển cho hệ thống gian lận của Facebook, TikTok hoặc Instagram.
Đối với người môi giới, điều này có nghĩa là tài khoản quảng cáo sẽ bị cấm ngay lập tức trước khi chiến dịch được khởi động. Đối với chuyên gia SMM, người quản lý 20-30 tài khoản của khách hàng, đây là rủi ro bị chặn hàng loạt ngay lập tức nhiều hồ sơ nếu chúng sử dụng một IP thực qua rò rỉ. Đối với người bán hàng, người đang quét Wildberries hoặc Ozon qua đa tài khoản, rò rỉ DNS có thể dẫn đến việc tất cả các yêu cầu "ẩn danh" được gán cho một địa chỉ thực duy nhất và nhanh chóng bị chặn theo địa lý.
Vấn đề chính là rò rỉ không thể nhìn thấy bằng mắt thường — hồ sơ mở bình thường, quảng cáo chạy, dòng thời gian tải. Vấn đề xuất hiện sau vài giờ hoặc vài ngày, khi thuật toán của nền tảng tích lũy thống kê và đối chiếu các địa chỉ IP giữa các hồ sơ khác nhau. Chính vì vậy, việc kiểm tra phải trở thành một phần của thói quen trước khi lần đầu tiên đăng nhập, chứ không phải là phản ứng với một lệnh cấm đã xảy ra.
WebRTC tiết lộ IP thực của bạn như thế nào
WebRTC (Web Real-Time Communication) là một giao thức tích hợp trong trình duyệt cho phép trao đổi trực tiếp âm thanh, video và dữ liệu giữa các thiết bị mà không cần sự tham gia của máy chủ. Để thiết lập một kết nối như vậy, trình duyệt phải biết địa chỉ IP công cộng và IP cục bộ thực của thiết bị thông qua cơ chế ICE (Interactive Connectivity Establishment). Nó thực hiện điều này bất kể proxy nào được cấu hình trong hệ thống hoặc trình duyệt, vì WebRTC hoạt động ở cấp độ ngăn xếp mạng, chứ không phải lưu lượng HTTP.
Trong thực tế, điều này diễn ra như sau: bạn truy cập Facebook qua một proxy cư trú với IP từ Đức, nhưng kịch bản trên trang thông qua WebRTC nhận được IP nhà hoặc IP làm việc của bạn từ Nga. Facebook ghi lại cả hai địa chỉ, so sánh vị trí địa lý, thấy sự không khớp và đánh dấu hồ sơ là đáng ngờ. Ngay cả khi lệnh cấm không xảy ra ngay lập tức, tài khoản rơi vào chế độ kiểm soát cao hơn — giới hạn hành động giảm, phạm vi quảng cáo giảm.
Các trình duyệt thông thường như Chrome và Firefox theo mặc định không chặn rò rỉ này — bạn cần phải tắt WebRTC thông qua các cờ hoặc sử dụng trình duyệt chống phát hiện với bảo vệ tích hợp. Dolphin Anty, AdsPower, Multilogin, GoLogin và Octo Browser có một công tắc riêng cho chế độ WebRTC: bạn có thể hoàn toàn tắt giao thức, thay thế IP công cộng bằng địa chỉ proxy hoặc chỉ để lại IP cục bộ mà không có công cộng. Đối với đa tài khoản, lựa chọn đúng là thay thế bằng IP proxy, chứ không phải tắt hoàn toàn, vì việc tắt hoàn toàn WebRTC có thể trở thành một mẫu có thể phát hiện.
Cách các yêu cầu DNS tiết lộ vị trí thực của bạn
Rò rỉ DNS xảy ra khi trình duyệt hoặc hệ điều hành gửi yêu cầu chuyển đổi tên miền thành IP không thông qua proxy, mà trực tiếp qua máy chủ DNS của nhà cung cấp. Điều này đặc biệt xảy ra với các proxy SOCKS5, mà theo mặc định không luôn luôn chặn lưu lượng DNS, khác với các proxy HTTP(S) với việc tạo hầm hoàn toàn. Kết quả là, trang web nhận được IP proxy cho các yêu cầu HTTP, nhưng máy chủ DNS của nhà cung cấp "thấy" khu vực thực của bạn, và thông tin này có thể được đối chiếu thông qua các kịch bản phân tích hoặc hệ thống chống gian lận bên ngoài.
Đối với người môi giới, người chạy quảng cáo qua Facebook Ads hoặc TikTok Ads từ một GEO cụ thể, rò rỉ DNS có nghĩa là nền tảng thấy nhà cung cấp từ một quốc gia, trong khi địa chỉ IP lại từ một quốc gia khác. Đây là một tín hiệu trực tiếp về việc sử dụng proxy, thường dẫn đến việc xác minh bổ sung hoặc chặn chiến dịch ở giai đoạn kiểm duyệt. Đối với một đại lý SMM, người quản lý tài khoản của khách hàng từ các thành phố khác nhau, rò rỉ DNS có thể tiết lộ rằng tất cả các hồ sơ thực sự được quản lý từ một vị trí, phá vỡ logic "các người khác nhau quản lý các tài khoản khác nhau".
Việc kiểm tra rò rỉ DNS riêng biệt với WebRTC là rất quan trọng, vì đây là hai kênh truyền dữ liệu khác nhau, và việc bảo vệ khỏi một không đảm bảo bảo vệ khỏi cái kia. Nhiều người mới chỉ thiết lập việc thay thế WebRTC và cho rằng hồ sơ đã được bảo vệ, quên rằng yêu cầu DNS có thể đi qua proxy nếu cấu hình của bộ điều hợp mạng không chính xác hoặc khi sử dụng proxy hệ thống thay vì proxy bên trong trình duyệt chống phát hiện.
7 kiểm tra trước khi đăng nhập vào hồ sơ
Dưới đây là trình tự hành động mà bạn nên thực hiện cho mỗi hồ sơ mới trước khi đăng nhập vào Facebook, Instagram, TikTok hoặc truy cập Wildberries bằng tài khoản mới.
- Kiểm tra loại proxy và giao thức. Đảm bảo rằng bạn đang sử dụng SOCKS5 hoặc HTTP(S) với hỗ trợ tạo hầm hoàn toàn cho DNS, chứ không phải SOCKS "trần" mà không có proxy DNS.
- Mở dịch vụ kiểm tra rò rỉ trước khi vào nền tảng. Truy cập browserleaks.com/webrtc và browserleaks.com/dns trong chính hồ sơ của trình duyệt chống phát hiện — không phải trong Chrome thông thường.
- So sánh IP công cộng với IP proxy. Địa chỉ mà dịch vụ hiển thị trong phần WebRTC phải trùng khớp với IP của proxy của bạn, chứ không phải với IP nhà hoặc di động.
- Kiểm tra danh sách máy chủ DNS. Trong phần Kiểm tra Rò rỉ DNS, tất cả các máy chủ phải thuộc về quốc gia và nhà cung cấp proxy, chứ không phải nhà cung cấp internet thực của bạn.
- Kiểm tra vị trí địa lý theo múi giờ và ngôn ngữ của trình duyệt. Múi giờ, ngôn ngữ hệ thống và vị trí địa lý trong hồ sơ của trình duyệt chống phát hiện phải tương ứng với quốc gia của IP proxy — sự không khớp cũng được coi là một mẫu đáng ngờ, mặc dù về mặt hình thức không phải là rò rỉ WebRTC/DNS.
- Kiểm tra hồ sơ trên whoer.net hoặc ipleak.net. Dịch vụ độc lập thứ hai cung cấp một kiểm tra kiểm soát — nếu cả hai dịch vụ hiển thị kết quả sạch giống nhau, rủi ro rò rỉ là tối thiểu.
- Ghi lại kết quả kiểm tra trong bảng theo dõi hồ sơ. Đối với các đại lý và nhóm quản lý hàng chục tài khoản, việc giữ nhật ký là rất quan trọng: ngày kiểm tra, IP proxy, kết quả kiểm tra WebRTC/DNS. Điều này tiết kiệm hàng giờ trong việc điều tra lệnh cấm hàng loạt.
Quan trọng
Việc kiểm tra cần được thực hiện ngay trong hồ sơ chống phát hiện, với proxy đang hoạt động, chứ không phải trong trình duyệt chính. Bài kiểm tra được thực hiện trong Chrome thông thường không phản ánh tình trạng của hồ sơ được cách ly với các tham số đã được thay thế.
Cài đặt bảo vệ trong Dolphin Anty, AdsPower, Multilogin, GoLogin
Trong Dolphin Anty, cài đặt WebRTC nằm trong phần tạo hồ sơ, tab "Proxy và WebRTC". Bạn cần chọn chế độ "Altered" (thay thế bằng IP proxy) thay vì "Disabled" — như vậy nền tảng sẽ thấy địa chỉ đã được đồng ý, chứ không phải là không có giao thức. Sau khi lưu hồ sơ, hãy chắc chắn mở nó và kiểm tra qua browserleaks.com trước khi đăng nhập vào tài khoản.
Trong AdsPower, tùy chọn tương tự được gọi là "WebRTC" trong tab Fingerprint khi tạo hồ sơ — hãy chọn tùy chọn "Replace" với việc tự động thay thế IP từ proxy. Tại đó cũng có khối DNS — nên bật "Use proxy DNS", để các yêu cầu DNS đi qua cùng một đường hầm với lưu lượng HTTP.
Trong Multilogin, bảo vệ WebRTC được tích hợp trong động cơ Mimic và Stealthfox, và theo mặc định thay thế IP công cộng bằng địa chỉ proxy mà không cần cài đặt thủ công — nhưng sau khi liên kết proxy mới, bạn nên cập nhật hồ sơ và kiểm tra lại, vì đôi khi cần phải tạo lại phiên.
Trong GoLogin và Octo Browser, cài đặt WebRTC nằm trong các tham số dấu vân tay của hồ sơ (Fingerprint), phần Mạng — hãy chọn chế độ thay thế dựa trên proxy, chứ không phải chặn hoàn toàn. Octo Browser còn cho phép bạn nhập thủ công máy chủ DNS tương ứng với quốc gia của proxy, điều này hữu ích khi làm việc với các GEO không chuẩn cho TikTok Ads hoặc Google Ads.
Đối với tất cả các trình duyệt được liệt kê, nguyên tắc chung là: trước tiên bạn cài đặt proxy, sau đó kiểm tra xem WebRTC và DNS có đồng bộ với proxy này hay không, và chỉ sau đó mở nền tảng cần thiết. Nếu bạn làm việc với proxy cư trú, rủi ro không khớp vị trí địa lý thấp hơn, vì IP thuộc về người dùng thực trong quốc gia cần thiết, và máy chủ DNS thường được liên kết hợp lý với khu vực này.
Dịch vụ kiểm tra rò rỉ
Để kiểm soát rò rỉ, chỉ cần ba đến bốn dịch vụ đã được kiểm chứng, cung cấp mức độ chi tiết khác nhau và cho phép đối chiếu kết quả.
| Dịch vụ | Kiểm tra cái gì | Khi nào sử dụng |
|---|---|---|
| browserleaks.com | WebRTC, DNS, Canvas, dấu vân tay của trình duyệt | Kiểm tra chính cho mỗi hồ sơ mới |
| ipleak.net | Sự trùng khớp IP, máy chủ DNS và vị trí địa lý | Kiểm tra kiểm soát sau lần đầu tiên |
| whoer.net | Ẩn danh, múi giờ, ngôn ngữ trình duyệt, cờ proxy | Trước khi khởi động các chiến dịch quảng cáo |
| dnsleaktest.com | Danh sách chi tiết các máy chủ DNS đang sử dụng | Khi nghi ngờ có rò rỉ DNS từ một proxy cụ thể |
Quy tắc đơn giản: nếu ít nhất một trong các dịch vụ hiển thị sự không khớp của IP hoặc máy chủ DNS với vị trí địa lý đã khai báo của proxy, hồ sơ không thể được sử dụng để đăng nhập vào tài khoản mục tiêu cho đến khi vấn đề được giải quyết.
Những sai lầm điển hình khi cài đặt proxy và hồ sơ
Sai lầm đầu tiên là sử dụng proxy hệ thống của hệ điều hành thay vì proxy được cấu hình bên trong trình duyệt chống phát hiện. Proxy hệ thống không áp dụng cho tất cả các quy trình, và một phần lưu lượng, bao gồm cả DNS, có thể đi trực tiếp qua nhà cung cấp.
Sai lầm thứ hai là tin tưởng vào các máy chủ DNS công cộng miễn phí mà không có liên kết với quốc gia của proxy. Nếu proxy được cấp ở Ba Lan, trong khi máy chủ DNS là một máy chủ công cộng của Mỹ, điều này tạo ra sự không khớp hợp lý mà các hệ thống chống gian lận tiên tiến của Facebook và TikTok ghi nhận.
Sai lầm thứ ba là tái sử dụng cùng một proxy cho nhiều hồ sơ mà không có sự luân chuyển. Ngay cả khi cài đặt WebRTC và DNS hoàn hảo, nếu 10 tài khoản đăng nhập từ một IP, nền tảng sẽ thấy một cụm hồ sơ liên quan và cấm chúng theo chuỗi khi một trong số chúng vi phạm lần đầu.
Sai lầm thứ tư là bỏ qua việc kiểm tra lại sau khi thay đổi proxy trong một hồ sơ đã tồn tại. Nhiều người thay đổi IP để "cập nhật" tài khoản, nhưng quên kiểm tra lại rò rỉ — cài đặt WebRTC có thể đã bị đặt lại khi cập nhật trình duyệt chống phát hiện.
Sai lầm thứ năm là sử dụng proxy trung tâm dữ liệu cho các nhiệm vụ mà sự tương đồng với người dùng thông thường là rất quan trọng, chẳng hạn như cho Instagram hoặc TikTok. Các nền tảng dễ dàng xác định IP của các trung tâm dữ liệu theo các dải ASN, và ngay cả khi bài kiểm tra WebRTC/DNS sạch, tài khoản vẫn rơi vào chế độ kiểm soát cao hơn chỉ vì bản chất của IP.
Loại proxy nào giảm thiểu rủi ro rò rỉ và cấm
Việc chọn loại proxy ảnh hưởng trực tiếp đến mức độ nhận thấy sự không khớp ngay cả khi trình duyệt chống phát hiện được cài đặt hoàn hảo.
| Loại proxy | Rủi ro phát hiện theo IP | Phù hợp cho |
|---|---|---|
| Proxy cư trú | Thấp | Facebook Ads, Instagram, TikTok, đa tài khoản |
| Proxy di động | Tối thiểu | TikTok Ads, làm nóng tài khoản, hệ thống chống gian lận nghiêm ngặt |
| Proxy trung tâm dữ liệu | Cao | Quét Wildberries, Ozon, nhiệm vụ không yêu cầu xác minh nghiêm ngặt |
Đối với các tài khoản quảng cáo và mạng xã hội, IP cư trú và di động giảm thiểu khả năng nền tảng bắt đầu chú ý đến hồ sơ, ngay cả khi về mặt kỹ thuật bài kiểm tra WebRTC/DNS đã được vượt qua sạch sẽ. Đối với việc quét các thị trường, nơi tốc độ và khối lượng yêu cầu quan trọng, proxy trung tâm dữ liệu vẫn là lựa chọn khả thi với điều kiện thường xuyên thay đổi IP.
Kết luận
Rò rỉ WebRTC và DNS không phải là một mối đe dọa lý thuyết, mà là nguyên nhân cụ thể của hầu hết các lệnh cấm "không rõ lý do" ngay sau lần đăng nhập đầu tiên vào hồ sơ mới. Việc kiểm tra theo danh sách kiểm tra 7 điểm mất từ 3-5 phút cho mỗi tài khoản, nhưng tiết kiệm hàng giờ trong việc phục hồi các hồ sơ bị cấm và giải thích cho khách hàng tại sao quảng cáo hoặc tài khoản Instagram đã biến mất.
Nếu bạn đang quản lý đa tài khoản trong Facebook Ads, TikTok Ads hoặc quản lý hồ sơ của khách hàng trên Instagram, chúng tôi khuyên bạn nên kết hợp cài đặt đúng WebRTC và DNS trong Dolphin Anty, AdsPower hoặc Multilogin với các proxy cư trú chất lượng — điều này giảm thiểu khả năng không khớp mà các hệ thống chống gian lận của nền tảng phát hiện, và làm cho mỗi hồ sơ ổn định hơn từ lần đăng nhập đầu tiên.