Giả mạo Googlebot: Cách website xác minh danh tính trình thu thập

Header User-Agent chỉ là một trường văn bản thuần túy, và không có gì ngăn bất kỳ đoạn script nào đặt nó thành Googlebot/2.1 (+http://www.google.com/bot.html). Các trình cào dữ liệu làm điều này liên tục, thường là để lách qua các bộ lọc bot đơn giản chỉ nhìn vào đúng chuỗi này. Trong khi đó, Googlebot thật, Bingbot, và hàng chục trình thu thập hợp pháp khác cũng tự giới thiệu mình theo đúng cách đó — bằng tên, trong đúng header đó. Một website muốn đối xử đặc biệt với "Googlebot" trước tiên phải trả lời một câu hỏi: liệu yêu cầu này có thực sự đến từ Google, hay chỉ đến từ bất kỳ ai gõ đúng mấy chữ đó?

Điểm chính cần nhớ

• Danh tính tự khai trong User-Agent tự nó không chứng minh được gì — đó là văn bản tự do, và sao chép chuỗi của một trình thu thập thật chỉ tốn một dòng code với bất kỳ ai muốn giả mạo nó.
• Reverse DNS được xác nhận hai chiều (forward-confirmed reverse DNS) là phép kiểm tra kinh điển: tra ai đang kiểm soát IP nguồn, rồi xác nhận ngược lại câu trả lời đó bằng các bản ghi DNS chính nhà vận hành công bố.
• Danh sách dải IP do nhà vận hành công bố là phương án thay thế nhanh và rẻ hơn với những nhà vận hành duy trì danh sách đó, đổi lại là độ trễ giữa các lần cập nhật.
• Chữ ký mật mã học (RFC 9421 / Web Bot Auth) thay thế suy luận bằng bằng chứng: một chữ ký được xác minh thành công cho biết khóa nào đã ký yêu cầu, chứ không chỉ yêu cầu đến từ mạng nào.
• Danh bạ nhà vận hành là lựa chọn mới nhất — BotBase của Cloudflare cho phép một nhà vận hành tự đăng ký danh tính để website tra cứu trực tiếp, và chính danh bạ này sẽ chạy lại giúp website các phép kiểm tra DNS, danh sách IP và chữ ký.
• Bốn phương pháp này xác minh những thứ khác nhau và thất bại theo những cách khác nhau, nên biết website đang dựa vào phương pháp nào cũng quan trọng không kém việc biết có tồn tại một phép kiểm tra hay không.

Lời tự khai thì miễn phí, bằng chứng thì không

Mỗi phép kiểm tra dưới đây tồn tại vì đúng một lỗ hổng: User-Agent là lời tự khai của client về chính nó, và client có thể khai bất cứ điều gì. Điều này cũng đúng với trình duyệt thông thường — bài viết của chúng tôi về phát hiện giả mạo User-Agent nói về đúng vấn đề này ở phía trình duyệt — nhưng một trình thu thập tự khai danh tính đặt cược cao hơn, vì các website tin tưởng "Googlebot" thường cấp cho nó những thứ không bao giờ cấp cho khách vãng lai ẩn danh: truy cập không giới hạn tốc độ, bỏ qua tường phí, hoặc bỏ qua thẳng trang thử thách. Xác minh lời khai đó, chứ không chỉ đọc nó, chính là toàn bộ nội dung bài viết này.

Phương pháp 1: Reverse DNS được xác nhận hai chiều

Phép kiểm tra lâu đời nhất và vẫn được dùng rộng rãi nhất chạy qua hai bước, và bỏ qua bước thứ hai chính là sai lầm khiến bước thứ nhất trở nên vô nghĩa.

Bước một — tra cứu ngược. Lấy địa chỉ IP nguồn của yêu cầu và tra bản ghi PTR của nó, bản ghi này ánh xạ một IP về một tên miền máy chủ. Nếu đây thực sự là trình thu thập của Google, tên miền này phải kết thúc bằng googlebot.com, google.com hoặc googleusercontent.com — đúng ba tên miền mà tài liệu xác minh chính thức của Google hướng dẫn chủ website chấp nhận.

Bước hai — xác nhận xuôi. Chỉ riêng tên miền từ bước một thì chưa chứng minh được gì, vì bản ghi PTR do bất kỳ ai quản trị vùng reverse DNS của địa chỉ IP đó kiểm soát — chứ không phải do bạn muốn ai là người vận hành địa chỉ đó. RFC 1912 ghi lại chính xác loại rủi ro cấu hình sai và lạm dụng DNS này, và thuật ngữ DNS trong RFC 8499 cũng khẳng định đúng điều đó về mặt cấu trúc: cái ta gọi là reverse DNS chỉ là chiều "từ địa chỉ sang tên" do hai vùng IN-ADDR.ARPA và IP6.ARPA phục vụ, với nội dung do chính bên được ủy quyền khối địa chỉ đó điền vào, chứ không phải một chứng chỉ do bên thứ ba đáng tin cấp phát. Vì vậy phép kiểm tra chưa xong. Website lấy tên miền từ bước một và phân giải nó theo chiều xuôi — một truy vấn A/AAAA thông thường — rồi kiểm tra kết quả có khớp với IP nguồn ban đầu không. Chỉ khi cả hai chiều khớp nhau, danh tính mới đứng vững: một kẻ tấn công không kiểm soát DNS của googlebot.com không thể khiến bản ghi PTR của một IP bất kỳ phân giải ra một tên miền mà khi phân giải xuôi lại trả về đúng IP đó.

Đây là lý do phiên bản hai bước này được gọi là reverse DNS "được xác nhận hai chiều", và cũng là lý do một lượt tra cứu ngược đơn lẻ không phải là một phương pháp xác minh — nó chỉ là tra một giá trị do người khác kiểm soát.

Phương pháp 2: Danh sách dải IP do nhà vận hành công bố

Một số nhà vận hành trình thu thập bỏ qua DNS hoàn toàn và công bố danh sách các dải IP mà họ dùng để thu thập dữ liệu. Website tải danh sách này về, kiểm tra IP nguồn của yêu cầu có nằm trong đó không, và coi là đã xác minh nếu khớp. Đây chỉ là một phép kiểm tra thành viên tập hợp — rẻ hơn nhiều so với hai lượt tra cứu DNS khứ hồi — điều này quan trọng ở khối lượng yêu cầu mà các trình thu thập lớn tạo ra.

Google công bố đúng những danh sách như vậy dưới dạng các file JSON chứa khối CIDR, tách theo từng nhóm trình thu thập: common-crawlers.json cho các crawler tìm kiếm, special-crawlers.json cho những sản phẩm như AdsBot, cùng các file riêng cho những lượt tải do người dùng kích hoạt. Tài liệu của Google trình bày việc đối chiếu với các file này như phương án tự động, đối lập với lượt tra cứu DNS thủ công — cùng một câu hỏi, câu trả lời rẻ hơn.

Đánh đổi nằm ở độ mới. Một danh sách dải IP được công bố chỉ là một ảnh chụp tại một thời điểm; nếu nhà vận hành thêm không gian địa chỉ mới mà bản sao được cache ở phía website chưa cập nhật kịp, một trình thu thập thật có thể tạm thời không qua được phép kiểm tra. Và phương pháp này chỉ tồn tại với những nhà vận hành đủ kỷ luật để công bố và duy trì danh sách ngay từ đầu — nhiều trình thu thập nhỏ hơn hoặc mới hơn không làm vậy.

Phương pháp 3: Chữ ký mật mã học

Cả DNS lẫn dải IP đều xác minh một mạng — bên đang nắm giữ khối địa chỉ đó, hoặc tuyên bố sở hữu dải đó. Chữ ký xác minh một thứ khác: bên đang nắm giữ một khóa riêng cụ thể. Nhà vận hành ký từng yêu cầu gửi đi bằng HTTP Message Signatures (RFC 9421), chuẩn mà bản dự thảo kiến trúc Web Bot Auth dựa vào — một Internet-Draft của IETF vẫn đang được sửa đổi và đổi tên, chưa phải một chuẩn hoàn chỉnh — rồi công bố khóa công khai tương ứng. Website xác minh chữ ký bằng khóa đó mà hoàn toàn không cần quan tâm yêu cầu đến từ địa chỉ IP nào.

Bài hướng dẫn kỹ thuật phát hiện bot của chúng tôi giải thích đầy đủ cơ chế này trong phần "Định danh bot bằng mật mã học: Web Bot Auth" — đáng đọc nếu bạn muốn hiểu phần mật mã học bên dưới; ở đây, điểm quan trọng hẹp hơn: phép kiểm tra chữ ký trả lời câu hỏi "khóa nào đã ký yêu cầu này", khác với câu hỏi "yêu cầu này đến từ mạng nào" — và câu trả lời cho hai câu hỏi đó đôi khi không khớp nhau, điều đáng lưu ý.

Phương pháp 4: Danh bạ nhà vận hành

Năm 2026 bổ sung câu trả lời thứ tư cho cùng một câu hỏi. Thay vì mỗi website tự suy luận danh tính từ địa chỉ mạng hay khóa, giờ đây nhà vận hành có thể đăng ký một lần vào một danh bạ, và để danh bạ đó làm việc suy luận thay cho tất cả. BotBase của Cloudflare dành cho nhà vận hành, ra mắt ngày 28 tháng 8 năm 2026, cho phép một nhà vận hành bot gửi và duy trì mục đăng ký của riêng mình — khai báo họ là ai, làm gì, và có thể xác minh họ bằng cách nào — rồi theo dõi hồ sơ đó qua các trạng thái như chờ duyệt, được chấp nhận hay bị từ chối, trước khi nhận được nhãn "Verified".

Điều quan trọng nằm ở chính khâu duyệt này. Cloudflare không tin ngay lời khai báo: họ kiểm tra xem phương thức xác minh được khai có thực sự đứng vững hay không, đối chiếu danh sách IP, cấu hình reverse DNS và chữ ký Web Bot Auth của nhà vận hành. Nói cách khác, danh bạ không thay thế ba phương pháp đầu — nó chạy cả ba một lần, tập trung, để từng website chỉ việc dùng một kết luận có sẵn thay vì mỗi nơi lại dựng lại đúng ba phép kiểm tra đó.

Nửa còn lại của bức tranh, ở phía chủ website, là Bot Preference Sync — đi theo chiều ngược lại: chủ website đặt chính sách của mình cho nhóm crawler tìm kiếm, agent và huấn luyện một lần duy nhất trong bảng điều khiển, rồi Cloudflare tự động viết các quy tắc tương ứng vào robots.txt của site đó. Đây là cơ chế chính sách, không phải cơ chế xác minh — nhưng hai thứ chỉ có ý nghĩa khi đi cùng nhau, vì một tùy chọn dành cho "Googlebot" chỉ đáng giá đúng bằng khả năng website nhận ra thứ đang đọc nó có thật là Googlebot hay không.

Vì sao thứ tự này không phải ngẫu nhiên

Bốn phép kiểm tra này không phải là cùng một thứ được làm tốt dần lên qua từng bước. Ba phương pháp đầu xác minh ba đối tượng thực sự khác nhau, phương pháp thứ tư chạy cả ba đó thay cho bạn, và mỗi phương pháp hỏng theo một kiểu riêng:

• Reverse DNS được xác nhận hai chiều và các dải IP công bố đều xác minh một mạng. Chúng thất bại nếu DNS cấu hình sai hoặc danh sách dải IP đã cũ — cả hai đều là kiểu chặn nhầm một trình thu thập thật; hiếm hơn nhiều là trường hợp kẻ tấn công bằng cách nào đó kiểm soát được cả vùng xuôi lẫn vùng ngược cho một địa chỉ mà họ có được (hiếm, nhưng không phải bất khả thi với kẻ tấn công có đủ nguồn lực).
• Chữ ký xác minh người nắm giữ khóa. Nó chỉ thất bại nếu khóa riêng bị rò rỉ — đây là vấn đề mật mã học và bảo mật vận hành, không liên quan gì đến DNS hay cấu trúc mạng.
• Mục trong danh bạ xác minh đúng những gì danh bạ đã kiểm tra hộ bạn. Nó mạnh đúng bằng các phép kiểm tra đứng sau nó, và thêm hai kiểu hỏng của riêng mình: việc thẩm định của chính danh bạ lỏng lẻo, và một nhà vận hành hợp pháp đơn giản là chưa kịp đăng ký.

Một website chỉ dựa vào duy nhất một trong các phép kiểm tra này thực chất đang tin tưởng đúng một kiểu thất bại mà không hề hay biết. Kết hợp chúng lại — tra cứu danh bạ trước, rồi lùi về phép kiểm tra DNS của chính mình với những nhà vận hành chưa có trong danh bạ — nghĩa là kẻ tấn công phải vượt qua nhiều hơn mắt xích yếu nhất, đồng thời một trình thu thập thật cũng không bị chặn nhầm chỉ vì một danh sách đã cũ.

Điều này có ý nghĩa gì với trình duyệt của chính bạn

Không phương pháp nào trong bốn phương pháp trên là thứ một trình duyệt thông thường có thể cung cấp. Chúng tồn tại cho các trình thu thập tự động tự khai danh tính ngay từ đầu; một người duyệt web bình thường không bao giờ gửi một danh tính tự khai cần được xác minh. Đó chính xác là lý do vì sao website dùng một bộ công cụ hoàn toàn khác cho khách truy cập thông thường — dấu vân tay trình duyệt và mạng — để dựng lại bức tranh về một phiên truy cập từ những tín hiệu chưa ai từng khai báo. Nếu muốn xem điều đó trông ra sao từ phía bên kia, công cụ phát hiện bot của BrowserInsight hiển thị đúng những tín hiệu quan sát được từ phía client mà một hệ thống phát hiện sẽ dùng cho một phiên không có danh tính tự khai nào để xác minh cả.

Phạm vi bài viết này được thu hẹp có chủ ý. Bài hướng dẫn này chỉ nói về một điều duy nhất — xác minh một trình thu thập đã tự khai một danh tính cụ thể. Nó không nói về cách chỉ dựa vào tín hiệu phía client để phân biệt tự động hóa không mong muốn, chưa khai báo, với khách truy cập thật (xem hướng dẫn kỹ thuật phát hiện bot của chúng tôi); nó không nói về một AI agent điều khiển trình duyệt thật của một người dùng thật bằng chính thông tin đăng nhập của họ (xem phát hiện lưu lượng AI agent); và nó cũng không nói về cách một con người chứng minh mình là người mà không bị theo dõi (xem chứng chỉ ẩn danh trên web). Mỗi vấn đề đó là một câu hỏi khác nhau với câu trả lời khác nhau; bài này chỉ tập trung vào việc biến "yêu cầu này tự nhận là Googlebot" từ một chuỗi được tin tưởng thành một sự thật đã được kiểm chứng.

Câu hỏi thường gặp

Tôi có thể tin ngay header User-Agent nếu nó ghi Googlebot không?

Không. User-Agent là văn bản thuần túy do client tự đặt, và không có gì ngăn một đoạn script sao chép y hệt chuỗi của một trình thu thập thật. Hãy coi lời khai trong User-Agent là một khẳng định cần xác minh, không phải một sự thật có sẵn — dùng một trong các phương pháp ở trên, chứ không phải tin vào bản thân chuỗi văn bản đó.

Sự khác biệt giữa reverse DNS và reverse DNS "được xác nhận hai chiều" là gì?

Một lượt tra cứu ngược (PTR) đơn thuần chỉ cho bạn biết tên miền nào mà người quản trị IP đó chọn công bố — điều này không chứng minh được gì nếu bạn vốn không tin người quản trị đó. Reverse DNS được xác nhận hai chiều thêm một bước: phân giải tên miền đó theo chiều xuôi một lần nữa và kiểm tra nó có khớp lại với IP ban đầu không. Bỏ qua bước xác nhận xuôi này là sai lầm phổ biến nhất trong phép kiểm tra này.

Chữ ký mật mã học có hẳn tốt hơn xác minh dựa trên DNS không?

Chúng xác minh những thứ khác nhau, nên "tốt hơn" phụ thuộc vào bạn cần gì. Chữ ký chứng minh khóa riêng nào đã ký một yêu cầu, độc lập với vị trí mạng, nên mạnh hơn trước hành vi giả mạo IP. Nhưng nó chỉ hoạt động với những nhà vận hành đã áp dụng việc ký, trong khi reverse DNS được xác nhận hai chiều hoạt động với bất kỳ nhà vận hành nào có DNS cấu hình đúng, bất kể họ có áp dụng chữ ký hay chưa.

Tôi có cần kiểm tra thêm dấu vân tay TLS hay TCP của yêu cầu không?

Đó là một tín hiệu bổ trợ riêng biệt, không phải thứ thay thế — hướng dẫn về TCP/IP fingerprinting của chúng tôi giải thích cách các đặc điểm ở tầng mạng có thể lộ ra sự không khớp giữa client tự khai và ngăn xếp thật của nó, hữu ích song song với việc xác minh danh tính, nhưng tự nó không xác nhận đây là trình thu thập của ai.

Xác minh Googlebot có bảo vệ trước mọi loại trình thu thập giả mạo không?

Nó chỉ bảo vệ trước một mối đe dọa cụ thể: một yêu cầu giả danh một nhà vận hành đã biết, có thể xác minh danh tính. Nó không làm được gì với việc cào dữ liệu chưa từng tự khai là Googlebot ngay từ đầu — loại lưu lượng đó cần các tín hiệu phát hiện bot rộng hơn được nêu trong hướng dẫn kỹ thuật phát hiện bot của chúng tôi, chứ không phải xác minh danh tính.

Đọc thêm

• Kỹ thuật phát hiện bot: Cách nhận diện bot và trình thu thập
• AI agent duyệt web: Website phân biệt với bot và người thật
• Chứng chỉ ẩn danh: Chứng minh bạn là người mà không bị theo dõi
• Cách phát hiện giả mạo user-agent (và vì sao dễ bị lộ)
• User-Agent là gì? Cách đọc và kiểm tra chuỗi của bạn
• TCP/IP Fingerprinting: Cách Máy Chủ Nhận Diện OS Trước TLS