Trình duyệt do Selenium khởi chạy có thể khác ở cổng gỡ lỗi, thuộc tính mà trang đọc được và cách khởi động. Một số thiết lập có thể cấu hình hợp lý để giữ tính nhất quán, còn việc cố che giấu chính trạng thái tự động hóa thì mong manh, không cần thiết và thường kém hiệu quả.
Khi chạy tự động hóa bằng Selenium, đôi khi logic của script hoàn toàn đúng nhưng vẫn không nhận được kết quả mong muốn. Phản ứng đầu tiên thường là thay đổi một hoặc hai tham số, nhưng thứ làm environment trở nên khác biệt thường không phải một công tắc riêng lẻ. Nó thường là tổ hợp của nhiều khác biệt trên nhiều lớp. Tách các lớp này ra sẽ giúp thấy rõ điều gì đáng cấu hình và điều gì làm cũng khó mang lại kết quả.
Cổng gỡ lỗi và dấu vết trong runtime
Cách Selenium điều khiển trình duyệt để lại hai loại dấu vết. Thứ nhất, khi khởi động trình duyệt có thể mở một cổng gỡ lỗi mà phần mềm bên ngoài có thể dùng để giành quyền điều khiển trang. Thứ hai, runtime environment có thể xuất hiện các thành phần bổ sung, chẳng hạn global variables có tiền tố cdc_ do driver chèn vào, các driver objects bổ sung trên window và một số phần của object prototypes bị thay đổi.
Những thành phần này không đến từ trang web mà từ chính driver. Nếu trình duyệt được khởi động theo cách tiêu chuẩn, chúng vẫn tồn tại bất kể script được viết tốt đến mức nào.
Các thuộc tính mà trang có thể đọc
Một loại dấu vết khác không nằm trong driver mà nằm trong JavaScript environment mà trang có thể đọc. Ví dụ được nhắc đến nhiều nhất là navigator.webdriver.
Thuộc tính này có ba giá trị khả dĩ. true nghĩa là trình duyệt đang được công cụ tự động hóa điều khiển, false nghĩa là không bị điều khiển, còn undefined nghĩa là không lấy được thông tin liên quan, thường do trình duyệt không công khai thuộc tính này hoặc nó đã được xử lý theo cách nào đó. Trong sử dụng bình thường của con người, giá trị thường là false hoặc undefined, còn Selenium mặc định khởi động với true.
Xung quanh đó còn có cả một nhóm tham số: User-Agent, hệ điều hành và phiên bản trình duyệt, độ phân giải màn hình, múi giờ, ngôn ngữ, Canvas, WebGL, AudioContext, danh sách font, model GPU và số lõi CPU. Khi ghép lại, chúng tạo thành thứ thường được gọi là browser fingerprint. Thiết bị của người dùng thật tự nhiên có fingerprints phân tán vì khác nhau về hệ thống, phần mềm và thói quen. Ngược lại, trình duyệt chạy với default automation configuration có thể tạo ra các tổ hợp rất giống nhau, khiến chúng dễ bị xếp vào các pattern đã biết.
Khác biệt do cách khởi động và thời gian render
Loại thứ ba không nằm ở một thuộc tính riêng lẻ mà xuất phát từ cách trình duyệt được khởi động và render tổng thể.
Khởi động với automation flags, chạy ở headless mode, kích thước cửa sổ không khớp với thông số màn hình, tổ hợp font rendering và graphics driver thiếu hợp lý, hoặc thời gian từ lúc tải trang đến khi tương tác được quá đồng đều — mỗi yếu tố riêng lẻ không phải là bằng chứng. Nhưng khi cộng lại, chúng có thể tạo thành một environment không giống thiết bị được người thật sử dụng.
Headless là ví dụ điển hình. Headless mode của Chrome phiên bản mới đã gần với trình duyệt bình thường hơn nhiều so với vài năm trước, nhưng so với regular mode thì vẫn có thể dễ lộ automation characteristics hơn, đặc biệt trên các site có risk controls nghiêm ngặt.
Những gì có thể cấu hình một cách hợp lý
Múi giờ, ngôn ngữ, độ phân giải màn hình và danh sách font không phải là yếu tố riêng của tự động hóa. Thiết bị thật vốn đã khác nhau tự nhiên. Điều quan trọng là tính nhất quán nội bộ: múi giờ phải phù hợp với khu vực của network exit, ngôn ngữ phù hợp với khu vực sử dụng thông thường, và độ phân giải không mâu thuẫn với hardware profile.
Nói đơn giản, mục tiêu không phải làm cho environment trông đặc biệt, mà là khiến các thông tin bên trong hợp lý với nhau. Nếu một thiết bị có vẻ truy cập từ Đức nhưng trình duyệt báo múi giờ U.S. West Coast, hệ thống chỉ có tiếng Anh và độ phân giải màn hình giống một virtual display điển hình, tổ hợp đó đã đủ nổi bật.
Đó cũng là lý do cấu hình environment nên được lưu trong một dạng có thể duy trì lâu dài. Hôm nay đổi múi giờ nhưng ngày mai quên ngôn ngữ có thể tạo ra sự thiếu nhất quán tệ hơn việc không đổi gì cả.
Những cách cố che giấu chính tự động hóa và vì sao không đáng làm
Một nhóm kỹ thuật khác nhắm trực tiếp vào dấu vết: xóa navigator.webdriver, xóa variables do driver chèn vào, ẩn driver objects hoặc bằng cách khác khiến bên phát hiện không đọc được automation status.
Vấn đề là các kỹ thuật này chỉ thay đổi bề mặt chứ không thay đổi hành vi bên dưới. Detection từ lâu không còn chỉ kiểm tra một thuộc tính; đọc attributes chỉ là lớp nông nhất. Một bản cập nhật driver, thay đổi thứ tự thực thi của detection script, hoặc detector bỏ qua JavaScript và xem trực tiếp low-level rendering results cùng tổ hợp device characteristics có thể khiến các chỉnh sửa trước đó mất tác dụng. Chi phí maintenance không thấp, trong khi lợi ích tiếp tục giảm.
Thực tế hơn, các thao tác như vậy thường rơi đúng vào vùng mà terms of service của nền tảng coi là né tránh technical protection measures. Script được viết gọn gàng cũng không làm thay đổi bản chất của hành động chỉ vì đã chỉnh vài properties.
Lớp mạng không thể xử lý trong script
Ngay cả khi browser environment có vẻ nhất quán, network layer vẫn có thể nhận diện session. Lớp này có thể xem IP thuộc data center, cloud server hay proxy network; historical reputation và ASN của dải IP; geolocation; mật độ requests từ cùng một IP; và liệu IP đó có truy cập nhiều accounts hoặc pages trong thời gian ngắn hay không. Cookies, Sessions và login state đi kèm requests cũng có thể được liên kết với nhau.
Những vấn đề này không thể giải quyết trong script mà phải xử lý ở environment layer: mỗi task có network exit riêng, exit region phù hợp với environment region và request pacing có thể kiểm soát. Khi cần cô lập nhiều task, các khả năng như PurpleMark thường hoạt động ở lớp này, cung cấp cho mỗi task một browser environment và network exit độc lập trong khi giữ geographic parameters nhất quán.
Thứ tự kiểm tra thực tế khi bị chặn
Một thứ tự hợp lý là: trước hết kiểm tra network layer về IP type, stability và geographic consistency; sau đó kiểm tra tính nhất quán nội bộ của environment giữa múi giờ, ngôn ngữ, độ phân giải và fonts; tiếp theo xem behavior timing, chẳng hạn waits có luôn là giá trị cố định hay input hoàn thành ngay lập tức; cuối cùng mới kiểm tra driver-level automation properties.
Lý do rất đơn giản: driver-level artifacts không còn là trọng tâm chính của detection. Đặt chúng ở bước đầu của troubleshooting thường chỉ tốn thời gian.
Ranh giới
Các biện pháp kỹ thuật có thể làm giảm khả năng bị nhận diện, nhưng có những giới hạn không nên vượt qua: tuân thủ quy tắc robots và terms of service của site mục tiêu, không thu thập thông tin cá nhân, không né tránh technical protection measures, kiểm soát tần suất requests và không ảnh hưởng đến hoạt động bình thường của dịch vụ bên kia.
