最近不少運(yùn)維和安全群在討論一種現(xiàn)象服務(wù)器訪問日志里突然出現(xiàn)大量 User-Agent 寫為 ClaudeBot、GPTBot 之類的請(qǐng)求但實(shí)際訪問路徑并不是頁(yè)面采集而是/.env、/.git/config、wp-login.php這類敏感文件探測(cè)。這不是官方 AI 爬蟲的正常行為而是有人故意偽造 AI Bot 的 User-Agent進(jìn)行大規(guī)模漏洞掃描。偽造者利用 AI 爬蟲名稱看起來(lái)合法、近兩年又頻繁出現(xiàn)在日志里的特點(diǎn)把掃描流量混在正常 Bot 流量中。對(duì)運(yùn)維和開發(fā)來(lái)說真正重要的是學(xué)會(huì)從 User-Agent 之外的信息確認(rèn)請(qǐng)求身份并在日志、WAF、封禁策略三層完成識(shí)別、驗(yàn)證和處置。如果你也在自己的 Nginx 或云安全產(chǎn)品里看到類似日志不要急著把所有 ClaudeBot 請(qǐng)求封掉也不要簡(jiǎn)單放行。這篇文章會(huì)從攻擊者為什么這樣做開始再給出一套從日志到封禁的最小落地流程。1. 為什么有人要偽造 ClaudeBot 這類 AI Bot 的 User-Agent1.1 偽裝掃描日志到底長(zhǎng)什么樣先看一段常見但很可疑的訪問日志203.0.113.7 - - [06/Feb/2025:03:11:22 0800] GET /.env HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.23 - - [06/Feb/2025:03:11:24 0800] GET /.git/config HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.24 - - [06/Feb/2025:03:11:27 0800] GET /wp-login.php HTTP/1.1 404 153 - Mozilla/5.0 (compatible; ClaudeBot/1.0)如果只看 User-Agent前幾行確實(shí)像某個(gè) AI 爬蟲在正常抓取。但請(qǐng)求路徑暴露了問題/.env環(huán)境變量文件、/.git/config源碼倉(cāng)庫(kù)配置、wp-login.phpWordPress 登錄入口這些都是漏洞掃描器最常探測(cè)的敏感路徑。攻擊者不在意返回 200 還是 404他們關(guān)心的是哪些路徑存在、哪些服務(wù)會(huì)響應(yīng)以及能否從響應(yīng)內(nèi)容中提取到價(jià)值信息。這類日志的特點(diǎn)是一條請(qǐng)求一個(gè)路徑來(lái)源 IP 可能分散UA 只在字面上“看起來(lái)像官方”但訪問規(guī)律和正常 AI 爬蟲完全不同。1.2 偽造 AI Bot 身份能帶來(lái)哪些好處攻擊者偽造 ClaudeBot 這類 AI 爬蟲名稱不是隨手寫的主要有幾個(gè)現(xiàn)實(shí)原因。第一個(gè)原因是繞過依賴 UA 的訪問控制。有些站點(diǎn)為了配合 AI 搜索收錄會(huì)在 Nginx 或 CDN 上專門放行ClaudeBot、GPTBot這類 UA有些團(tuán)隊(duì)還會(huì)把它們加入白名單認(rèn)為它們不會(huì)帶來(lái)威脅。攻擊者偽造這個(gè) UA相當(dāng)于直接借用了白名單身份。第二個(gè)原因是規(guī)避基于惡意 UA 的基礎(chǔ)封禁。像 sqlmap、Nikto、wpscan 這些掃描工具的 UA 特征非常明顯很多 IPS、WAF 有現(xiàn)成規(guī)則可以直接攔截。把 UA 改成 ClaudeBot 之后傳統(tǒng)規(guī)則失效流量更容易到達(dá)業(yè)務(wù)服務(wù)器。第三個(gè)原因是降低人工分析時(shí)的警惕性。安全告警每天會(huì)產(chǎn)生大量日志看到 ClaudeBot、GPTBot 這類名稱很多分析師第一反應(yīng)是“正常 AI 爬蟲”不會(huì)第一時(shí)間深入排查。攻擊者利用的正是這種思維慣性。1.3 User-Agent 是自述身份不能作為唯一依據(jù)需要注意HTTP 協(xié)議中的 User-Agent 是請(qǐng)求方自己聲明的“身份”客戶端可以隨意修改。用一行命令就能演示curl -A ClaudeBot/1.0 https://example.com/robots.txt服務(wù)器端收到這個(gè)請(qǐng)求后只能看到User-Agent: ClaudeBot/1.0無(wú)法判斷發(fā)請(qǐng)求的到底是 ClaudeBot 官方爬蟲還是某個(gè)掃描器?；谕瑯拥脑砉粽咄耆梢栽趻呙枘_本里偽造任意 UA。所以對(duì) User-Agent 的正確態(tài)度是它只能作為第一層分流標(biāo)識(shí)不能作為信任依據(jù)。真正要判斷一個(gè)流量是否可信必須組合來(lái)源 IP、請(qǐng)求行為、訪問頻率和路徑特征來(lái)判斷。2. 三層識(shí)別法從身份、來(lái)源、行為判斷真假2.1 第一層身份核對(duì) UA 字符串本身雖然 UA 可以偽造但它仍然是第一道過濾條件。這里要做的是“精確匹配”而不是“模糊包含”。以 ClaudeBot 為例官方爬蟲的 UA 命名通常有固定格式一般形如ClaudeBot/1.0或Mozilla/5.0 (compatible; ClaudeBot/1.0; 官方說明頁(yè))。如果日志里出現(xiàn)ClaudeBot/1.0后面還拼接了.net、.php、scanner、test等字符或者大小寫、空格明顯異常就需要懷疑是偽造樣本。更嚴(yán)謹(jǐn)?shù)淖龇ㄊ蔷S護(hù)一個(gè)“已知 AI Bot UA 樣本庫(kù)”。這個(gè)樣本庫(kù)包括三部分官方公開文檔中聲明的 UA 格式。線上訪問日志中確認(rèn)為官方爬蟲的 UA。社區(qū)報(bào)告確認(rèn)過存在偽造的 UA 變體。判斷原則很簡(jiǎn)單字符串完全匹配可能有風(fēng)險(xiǎn)需要繼續(xù)看下一層字符串不匹配但行為像抓取器可能是普通爬蟲也可能是掃描器同樣要繼續(xù)看來(lái)源和行為。2.2 第二層來(lái)源IP 段、ASN 與反向 DNS來(lái)源驗(yàn)證是識(shí)別偽造 AI Bot 最重要的手段。User-Agent 可以隨便改但正常情況下一個(gè) TCP 連接必須有真實(shí)的源 IP攻擊者可以使用大量 IP 發(fā)起掃描但很難讓自己的一臺(tái)掃描機(jī)同時(shí)出現(xiàn)在正確的云廠商網(wǎng)段里。先看 IP 歸屬whois 203.0.113.7查詢結(jié)果會(huì)顯示 IP 所在網(wǎng)段、運(yùn)營(yíng)商和組織名稱。比如查詢到Organization: Example Cloud、CIDR: 203.0.113.0/24這時(shí)再看這個(gè)組織是否與官方 AI 爬蟲公開的網(wǎng)段一致。再看反向 DNSdig -x 203.0.113.7官方爬蟲的 IP 通常會(huì)配置反解反解域名會(huì)包含明顯標(biāo)識(shí)比如某個(gè)爬蟲名稱或官方域名后綴。如果源 IP 反解結(jié)果為空或者反解域名是一串隨機(jī)數(shù)字甚至指向一個(gè)與 AI 爬蟲完全無(wú)關(guān)的 IDC 機(jī)房那么即使 UA 寫得再像官方也要提高警惕。這里的難點(diǎn)是官方 AI 爬蟲不一定會(huì)公開完整的 IP 清單部分云廠商 IP 還會(huì)動(dòng)態(tài)變化。所以來(lái)源信息不能作為絕對(duì)判斷要結(jié)合行為一起看。2.3 第三層行為請(qǐng)求路徑、頻率和抓取順序正常 AI 爬蟲的工作方式通常有清晰的抓取順序先請(qǐng)求robots.txt再根據(jù) sitemap 或頁(yè)面里的鏈接去抓取頁(yè)面內(nèi)容請(qǐng)求的路徑大多是可訪問的業(yè)務(wù) URL頻率相對(duì)可控。漏洞掃描器不是這樣工作的。掃描器通常攜帶一份路徑字典按字典順序挨個(gè)發(fā)起請(qǐng)求比如/.env /.git/HEAD /.git/config /wp-login.php /wp-admin/ /api/v1/ /actuator/env /backup.sql它們不會(huì)先看 robots.txt也不會(huì)在意頁(yè)面結(jié)構(gòu)和鏈接關(guān)系只關(guān)心路徑是否存在、響應(yīng)狀態(tài)碼是什么、返回內(nèi)容里有沒有敏感信息。如果一個(gè)“ClaudeBot”在同一個(gè) IP 下十秒內(nèi)連續(xù)請(qǐng)求這些路徑那基本可以確定不是官方 AI Bot而是偽造 UA 的掃描行為。還可以觀察請(qǐng)求頻率是否規(guī)律。正常抓取會(huì)有一定間隔掃描器為了趕時(shí)間常常高并發(fā)。如果同一個(gè) UA 在凌晨?jī)扇c(diǎn)對(duì)同一臺(tái)服務(wù)器發(fā)起幾百個(gè)不同路徑的請(qǐng)求而且大部分是 404攻擊的可能性很高。2.4 三層組合判斷不要只看單一條件維度正常 AI Bot 常見表現(xiàn)偽造 AI Bot 常見表現(xiàn)UA 匹配UA 與官方公開字符串一致格式穩(wěn)定UA 相似但夾雜異常字符或版本不一致來(lái)源 IP來(lái)自官方或合作云廠商網(wǎng)段可能有固定 ASN來(lái)源分散在多個(gè) IDCASN 與官方聲明不一致反查 DNS反解域名包含可識(shí)別標(biāo)識(shí)無(wú)反解或反解指向無(wú)關(guān)域名訪問路徑先請(qǐng)求 robots.txt再抓取業(yè)務(wù)鏈接直接路徑枚舉/.env、/.git/config等抓取頻率有間隔并發(fā)受控短時(shí)間高頻請(qǐng)求規(guī)律不明顯參考鏈接一般帶正常 Referer請(qǐng)求頭完整缺少 RefererHeader 不自然單條請(qǐng)求命中某一項(xiàng)不能說明什么比如正常業(yè)務(wù)方也可能偶爾訪問/.env路徑。但如果“UA 匹配 來(lái)源可疑 敏感路徑 高頻”這四件事同時(shí)出現(xiàn)基本可以進(jìn)入攔截流程。3. 落地檢測(cè)從 Nginx 訪問日志找出可疑 Bot 流量3.1 先統(tǒng)一日志格式保證能取到關(guān)鍵字段在排查之前要確保 Nginx 訪問日志記錄了足夠信息。推薦使用包含客戶端 IP、時(shí)間、請(qǐng)求、狀態(tài)碼和 UA 的格式log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent; access_log /var/log/nginx/access.log main;如果業(yè)務(wù)部署在 CDN 或七層負(fù)載均衡后面$remote_addr可能是 CDN 節(jié)點(diǎn) IP而不是真實(shí)客戶端 IP。這種情況要使用X-Forwarded-For或 CDN 平臺(tái)提供的真實(shí)客戶端 IP 變量但同時(shí)要注意這些 Header 可以被偽造。生產(chǎn)環(huán)境必須先驗(yàn)證源站是否只信任來(lái)自 CDN 的請(qǐng)求避免攻擊者直接偽造 Header 繞過記錄。3.2 用 Python 腳本按特征聚合可疑請(qǐng)求先統(tǒng)計(jì) UA 里出現(xiàn) ClaudeBot、GPTBot、Bytespider 等關(guān)鍵詞的 IP找出最活躍的來(lái)源from collections import Counter from pathlib import Path log_file Path(/var/log/nginx/access.log) fake_ua_keywords (ClaudeBot, GPTBot, Bytespider) sensitive_path (/.env, .git/config, wp-login.php, actuator, .bak, .sql) ip_counter Counter() sensitive_counter Counter() lines log_file.read_text(encodingutf-8, errorsignore).splitlines() for line in lines: if not any(keyword in line for keyword in fake_ua_keywords): continue fields line.split() if not fields: continue ip fields[0] ip_counter[ip] 1 if any(path in line for path in sensitive_path): sensitive_counter[ip] 1 print(出現(xiàn)偽造 AI UA 關(guān)鍵詞的 Top 20 IP) for ip, count in ip_counter.most_common(20): print(f{count:8d} {ip}) print(命中敏感路徑的 Top 20 IP) for ip, count in sensitive_counter.most_common(20): print(f{count:8d} {ip})這個(gè)腳本的思路是先篩選 UA再篩選路徑最后按 IP 聚合。實(shí)際生產(chǎn)環(huán)境不需要硬編碼在腳本里可以把日志接入 ELK、ClickHouse 或云原生日志服務(wù)用同樣的邏輯做可視化統(tǒng)計(jì)。這里要注意一個(gè)坑不要直接在整個(gè)日志文件上一次性過濾。生產(chǎn)環(huán)境日志量很大建議先tail -100000或按時(shí)間窗口切分日志再進(jìn)行分析。3.3 時(shí)間維度瞬時(shí)突增是更可靠的信號(hào)IP 數(shù)量和路徑命中只是其中一個(gè)維度。偽造 UA 的掃描器往往會(huì)在短時(shí)間內(nèi)集中爆發(fā)所以把時(shí)間維度加進(jìn)來(lái)判斷更準(zhǔn)確。統(tǒng)計(jì)指定時(shí)間內(nèi)每分鐘請(qǐng)求量tail -100000 /var/log/nginx/access.log \ | grep ClaudeBot \ | cut -d[ -f2 | cut -d] -f1 | cut -d: -f1-3 \ | sort | uniq -c | sort -rn | head -20輸出結(jié)果類似147 06/Feb/2025:03:11 98 06/Feb/2025:03:12 12 06/Feb/2025:03:13如果同一個(gè)來(lái)源 IP 在某一分鐘內(nèi)連續(xù)產(chǎn)生幾十條到上百條請(qǐng)求而且請(qǐng)求路徑全是/.env、/.git/config、wp-login.php這類路徑說明這不是正常 AI Bot 的抓取節(jié)奏而是掃描器正在跑字典。時(shí)間窗口聚合的價(jià)值在于它能把“少量誤報(bào)”和“批量掃描”區(qū)分開。正常抓取也會(huì)請(qǐng)求多個(gè)路徑但不會(huì)在幾秒內(nèi)密集命中大量敏感路徑。建議把“單位時(shí)間內(nèi)同一個(gè) IP 命中敏感路徑次數(shù)”作為告警條件而不是單純看 UA。這樣即使對(duì)方換個(gè) UA 名稱只要行為仍然是掃描一樣能觸發(fā)。4. 自動(dòng)處置從 Fail2ban 到 WAF 策略4.1 Fail2ban 攔截“敏感路徑 偽 AI UA”在單臺(tái) Linux 服務(wù)器上快速落地時(shí)Fail2ban 是成本最低的方案。思路是在 Nginx 訪問日志中匹配特定 UA 和敏感路徑超過閾值后自動(dòng)封禁源 IP。先創(chuàng)建過濾器比如/etc/fail2ban/filter.d/fake-ai-bot.conf[Definition] failregex ^HOST .*(?:GET|POST|HEAD) \/(?:\.env|\.git\/config|wp-login\.php|\.\.\/\.\.\/).* 404 .*ClaudeBot/1\.0$ ignoreregex 再在/etc/fail2ban/jail.local中啟用[fake-ai-bot] enabled true port http,https filter fake-ai-bot logpath /var/log/nginx/access.log findtime 60 maxretry 5 bantime 3600參數(shù)含義參數(shù)說明示例值findtime統(tǒng)計(jì)時(shí)間窗口單位秒60maxretry時(shí)間窗口內(nèi)匹配的最大次數(shù)5bantime封禁時(shí)長(zhǎng)單位秒3600logpath日志文件路徑/var/log/nginx/access.log配置完成后先測(cè)試正則是否匹配真實(shí)日志fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/fake-ai-bot.conf這個(gè)工具會(huì)顯示匹配次數(shù)。如果正則不匹配需要檢查日志格式與正則中的字段順序。4.2 WAF 的挑戰(zhàn)與限流思路Fail2ban 適合單機(jī)和簡(jiǎn)單場(chǎng)景但對(duì)于多節(jié)點(diǎn)、分布式掃描和 CDN 場(chǎng)景更推薦在 WAF 層處理。WAF 通常提供三種能力Bot 管理識(shí)別常見爬蟲和工具 UA并支持自定義 Bot 特征。JS Challenge對(duì)可疑請(qǐng)求下發(fā)一段 JavaScript 挑戰(zhàn)正常瀏覽器能通過大多數(shù)命令行掃描工具無(wú)法完成。速率限制按 IP、Session、UA 組合限流。實(shí)際策略不要直接對(duì) ClaudeBot 返回 403而是先分級(jí)正常且可驗(yàn)證的官方 AI Bot - 放行并限速 可疑 UA 但來(lái)源未知 - JS Challenge 或 429 疑似掃描 命中敏感路徑 - 403 或封禁這樣的好處是減少誤傷。有些站點(diǎn)希望被 AI 搜索索引如果把所有 ClaudeBot 都封掉可能會(huì)造成收錄異常。進(jìn)入挑戰(zhàn)流程后官方 Bot 即使無(wú)法完成 JS 挑戰(zhàn)也有機(jī)會(huì)通過后續(xù) IP 驗(yàn)證流程放行。4.3 封禁、觀察、復(fù)核的完整處理流程任何自動(dòng)封禁都可能誤傷尤其涉及到 AI Bot 名稱時(shí)。建議按下面順序執(zhí)行自動(dòng)發(fā)現(xiàn)日志或 WAF 識(shí)別到“UA 疑似 AI Bot 敏感路徑 高頻”。臨時(shí)限速先對(duì)該 IP 啟用較慢的限速策略而不是直接 403。人工復(fù)核查看 IP 歸屬、ASN、反向 DNS 和該 IP 的完整請(qǐng)求序列。確認(rèn)封禁如果確認(rèn)為掃描再封禁 IP 或 IP 段并設(shè)置合理時(shí)長(zhǎng)。定期復(fù)查每天檢查被誤殺的請(qǐng)求調(diào)整規(guī)則。保留證據(jù)把原始日志、請(qǐng)求頭和響應(yīng)狀態(tài)保存下來(lái)便于后續(xù)調(diào)整規(guī)則。這里重點(diǎn)強(qiáng)調(diào)第六步。很多團(tuán)隊(duì)封完就不管了后來(lái)才發(fā)現(xiàn)某個(gè)正常爬蟲 IP 被規(guī)則誤傷。保留日志和規(guī)則快照可以讓誤傷恢復(fù)變得可操作而不是只能靠“感覺”。5. 避免誤傷官方 AI Bot 和偽造掃描器怎么區(qū)分處理5.1 官方 AI Bot 通常會(huì)有哪些可驗(yàn)證特征雖然不同 AI 爬蟲的實(shí)現(xiàn)細(xì)節(jié)不同但公開服務(wù)通常有相對(duì)穩(wěn)定的特征會(huì)遵守robots.txt并且很多官方文檔會(huì)說明爬蟲用途和聯(lián)系頁(yè)面。會(huì)使用固定 UA并且 UA 中可能包含官方說明頁(yè)地址。來(lái)源 IP 有較明確的云廠商或自有網(wǎng)段部分會(huì)公布 IP 范圍。抓取行為以采集頁(yè)面內(nèi)容為主不會(huì)高頻請(qǐng)求/.git、/.env這類路徑。官方 AI Bot 也不一定永遠(yuǎn)表現(xiàn)完美比如某些海外云廠商的爬蟲會(huì)訪問不支持的地域、頻繁請(qǐng)求動(dòng)態(tài)接口但這不能作為直接封禁理由。更好的做法是建立“正常樣本”和“可疑樣本”兩個(gè)隊(duì)列持續(xù)觀察。5.2 參考分級(jí)處理策略情況建議處理UA 匹配IP 歸屬正常訪問路徑正常放行并設(shè)置每秒請(qǐng)求數(shù)上限UA 匹配IP 歸屬未知但路徑正常臨時(shí)放行記錄日志并持續(xù)觀察UA 匹配IP 歸屬未知命中敏感路徑限速觀察后續(xù)行為UA 匹配IP 歸屬可疑高頻命中敏感路徑直接封禁至少封禁 24 小時(shí)UA 不匹配但行為與官方 AI Bot 一致按普通爬蟲處理不做特殊放行在生產(chǎn)環(huán)境里建議把“UA 匹配”和“行為匹配”分開記分而不是用布爾判斷。例如UA 匹配官方格式1 IP 歸屬在官方網(wǎng)段3 先請(qǐng)求 robots.txt2 命中敏感路徑-3 短時(shí)間高頻請(qǐng)求-2 缺少 Referer-1最終分越高越可信越低越可疑。這樣即使攻擊者不斷更換 UA只要行為特征不變分?jǐn)?shù)依然會(huì)偏低。提醒最好不要在規(guī)則里寫死“只要 UA 等于 ClaudeBot 就放行”。AI 爬蟲名稱會(huì)不斷增加和變化要把判斷重點(diǎn)放在“來(lái)源和行為”上。6. 生產(chǎn)環(huán)境排錯(cuò)與預(yù)防清單6.1 接到告警后的排查順序如果線上已經(jīng)出現(xiàn)大量偽造 AI Bot 掃描建議按下面的順序排查而不是先找封禁命令。第一步看告警信息和時(shí)間窗口確認(rèn)是哪臺(tái)服務(wù)器、哪個(gè)域名、什么時(shí)間段開始異常。第二步提取原始日志不要只看聚合結(jié)果。先從日志里復(fù)制幾條最可疑的完整請(qǐng)求行看 UA、路徑、狀態(tài)碼、Referer 和來(lái)源 IP。第三步驗(yàn)證來(lái)源 IP。使用 whois、ASN 查詢和反向 DNS 解析判斷該 IP 是否在 AI Bot 官方網(wǎng)段范圍內(nèi)。這里要注意很多攻擊者會(huì)使用云主機(jī)IP 歸屬看起來(lái)也是正常云廠商所以不能只看“是不是云廠商”要看“是不是官方公告中使用的云廠商和網(wǎng)段”。第四步確認(rèn) CDN 場(chǎng)景下是否拿到真實(shí) IP。如果源站只信任 CDN 轉(zhuǎn)發(fā)請(qǐng)求日志里出現(xiàn)的客戶端 IP 才可信如果攻擊者直接訪問源站入口日志里記錄的 IP 可能不是真實(shí)攻擊源。第五步再?zèng)Q定處置動(dòng)作。如果是少量誤報(bào)先限速后觀察如果是大規(guī)模掃描就加入 WAF 規(guī)則或臨時(shí)封禁。6.2 上線前和日常防護(hù)檢查清單很多服務(wù)器既沒有統(tǒng)一的訪問日志格式也沒有 WAF 規(guī)則出了問題只能臨時(shí)翻日志。下面這份清單可以用于新服務(wù)上線前檢查也適合作為日常巡檢項(xiàng)訪問日志是否記錄了完整 UA、Referer、狀態(tài)碼和響應(yīng)時(shí)間。是否有/.env、/.git、/wp-login.php、/actuator等敏感路徑的訪問告警。是否對(duì)源站入口做了訪問控制避免 CDN 后的真實(shí) IP 泄露。是否配置了限速策略尤其是 UA 為常見 AI Bot 的請(qǐng)求。是否維護(hù)了已知 AI Bot IP 段和 UA 樣本庫(kù)并定期更新。是否有誤報(bào)回滾機(jī)制封禁后如何快速放行正常爬蟲。是否對(duì)封禁規(guī)則做每日或每周復(fù)盤。其中“源站真實(shí) IP 泄露”經(jīng)常被忽略。攻擊者可以直接掃描源站 IP繞過云 WAF即使你把 WAF 規(guī)則寫得再好也會(huì)失去意義。所以生產(chǎn)環(huán)境要確保源站只允許 CDN 節(jié)點(diǎn)、負(fù)載均衡器或白名單網(wǎng)段訪問。6.3 從“封 UA”升級(jí)到“行為基線”長(zhǎng)期來(lái)看只靠 UA 關(guān)鍵詞做防御是不夠的。攻擊者會(huì)不斷學(xué)習(xí)新的 UA 名稱今天偽裝 ClaudeBot明天就可能偽裝其它 AI 爬蟲。真正有效的方式是建立流量行為基線正常業(yè)務(wù)接口的