來源：https://blog.csdn.net/2403_87969572/article/details/155878638

抓取時間（ISO本地）：2026-05-18 05:17:18

---

一、前言：爬蟲突然“罷工”的突發狀況

最近筆者在做一個開源項目分析的小工具，核心需求是通過Selenium自動化爬取Gitee平臺上特定倉庫的貢獻者數據、提交記錄等信息。這個爬蟲腳本已經穩定運行了近一週，每天定時執行都能順利獲取數據。但就在前天，腳本突然徹底“罷工”——每次啟動Selenium驅動Edge瀏覽器訪問Gitee首頁時，都會直接彈出“安全驗證”提示框，無論等待多久都無法自動跳轉，手動干預也無法正常進入網站，這讓整個數據採集工作陷入停滯。

當時彈出的驗證界面有兩個關鍵狀態：第一個是初始的安全驗證彈窗，提示“檢測到您的訪問可能存在安全風險，請完成驗證”，界面中央只有一個“確認”按鈕，點擊後不會立即跳轉，而是進入第二個提示界面，明確顯示“當前環境正在被測試”，隨後便陷入無限加載狀態，無法進入Gitee的正常頁面。以下是當時截取的關鍵界面截圖，完整記錄了報錯場景：

考慮到項目 deadlines臨近，筆者立刻投入到問題排查中，前後嘗試了多種主流的反反爬方案，過程頗為曲折，最終卻被一個極其簡單的方法意外解決，特此記錄整個過程，希望能給遇到同類問題的開發者提供參考。

二、解決過程：那些“看似有效”的排查嘗試

面對Gitee的反爬攔截，我的第一反應是Selenium的自動化特徵被網站識別了。畢竟這類平臺的反爬機制通常會針對自動化工具的獨特標識進行檢測，因此我優先從“隱藏Selenium特徵”和“優化訪問環境”兩個方向展開嘗試，每一步都做了詳細的操作記錄和結果驗證。

1. 方向一：隱藏Selenium的自動化特徵

查閱資料可知，Selenium驅動瀏覽器時會留下一些明顯的“指紋”，比如Chrome/Edge瀏覽器的window.navigator.webdriver屬性會被設置為true，這是很多反爬機制的核心檢測點。為此我針對性地添加了一系列反檢測參數，具體操作如下：

• 添加瀏覽器啟動參數：在初始化EdgeDriver時，配置了–excludeSwitches=enable-automation（禁用自動化提示）、–disable-blink-features=AutomationControlled（禁用自動化控制特徵）等參數，同時關閉了瀏覽器的擴展程序和預加載功能，代碼片段如下：

from selenium import webdriver
from selenium.webdriver.edge.options import Options

edge_options = Options()
# 隱藏自動化提示
edge_options.add_experimental_option('excludeSwitches', ['enable-automation'])
# 禁用自動化控制特徵
edge_options.add_argument('--disable-blink-features=AutomationControlled')
# 關閉擴展
edge_options.add_argument('--disable-extensions')
# 禁用預加載
edge_options.add_argument('--no-first-run')

driver = webdriver.Edge(options=edge_options)

• 修改webdriver屬性：通過執行JavaScript代碼，強制將window.navigator.webdriver設置為undefined，試圖繞過前端檢測：

driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {
  "source": """
    Object.defineProperty(navigator, 'webdriver', {
      get: () => undefined
    })
  """
})

然而，即使完成了上述配置，重啟爬蟲後問題依然存在——安全驗證彈窗還是會準時出現，webdriver屬性的修改並未起到預期效果。我通過在瀏覽器控制檯手動查看該屬性，確認修改已生效，這說明Gitee的檢測機制可能不止依賴前端的webdriver標識。

2. 方向二：優化網絡環境與訪問策略

排除了Selenium特徵的問題後，我猜測可能是IP地址被Gitee標記為“風險IP”。畢竟爬蟲腳本每天會發起上百次請求，雖然已經做了10秒以上的請求間隔，但仍有可能觸發頻率限制。為此我嘗試了以下幾種網絡調整方案：

• 切換本地網絡：將電腦網絡從家庭WiFi切換到手機熱點，使用移動數據網絡訪問Gitee。此時IP地址已完全更換，但啟動爬蟲後依然彈出安全驗證，排除了單一IP被封禁的可能。
• 使用VPN切換地區：啟用常用的VPN工具，將節點切換至北京、上海等不同城市的服務器，再次嘗試爬蟲訪問。結果依舊不理想，安全驗證彈窗沒有任何變化，甚至出現了“地區訪問限制”的附加提示。
• 降低請求頻率與模擬人工操作：在腳本中添加了隨機請求間隔（15-25秒），同時加入了模擬鼠標移動、隨機點擊頁面空白處等操作，試圖讓訪問行為更貼近人工。但這些優化措施同樣未能突破攔截，點擊安全驗證的“確認”按鈕後，還是會陷入“當前環境正在被測試”的無限加載。

連續嘗試多種方案均告失敗後，我開始懷疑問題是否出在瀏覽器本身或者系統環境上，甚至嘗試更換了Chrome瀏覽器和對應的ChromeDriver，但最終的攔截結果完全一致，這讓排查陷入了僵局。

三、最終解決方案、

在所有技術手段都嘗試無果後，我抱著“死馬當活馬醫”的心態，決定放棄Selenium，直接用手動方式訪問Gitee網站，看看是否能發現一些線索。沒想到這個看似“無用”的操作，卻成了破解問題的關鍵。

具體操作過程非常簡單：關閉了所有通過Selenium啟動的瀏覽器窗口，直接雙擊桌面的Edge瀏覽器圖標，在地址欄輸入Gitee的官方網址（https://gitee.com/）。令人意外的是，手動訪問時同樣彈出了最初的安全驗證彈窗——這說明問題可能不是Selenium專屬的，而是當前設備或瀏覽器環境被Gitee標記了風險。

我點擊了彈窗中的“確認”按鈕，與Selenium自動化訪問不同的是，這次頁面僅加載了大約3-5秒，就順利通過了驗證，直接跳轉到了Gitee的登錄界面。登錄後我測試了瀏覽倉庫、查看提交記錄等操作，所有功能都完全正常，沒有再出現任何攔截提示。以下是手動訪問成功進入網站的截圖：

驚喜的是，在手動訪問通過驗證後，我重新啟動了之前的Selenium爬蟲腳本，發現安全驗證彈窗竟然消失了，爬蟲能夠正常訪問Gitee並獲取數據，就像之前從未出現過問題一樣。

四、原因分析與經驗總結

結合整個排查過程和最終結果，我推測Gitee的反爬機制採用了“環境風險標記+人工驗證解鎖”的邏輯：

1. 最初由於爬蟲的高頻訪問，我的瀏覽器環境（可能關聯了Cookie、瀏覽器指紋等信息）被Gitee標記為“高風險”，無論後續是通過Selenium還是自動化工具訪問，都會觸發強制安全驗證。
2. Gitee的安全驗證機制能夠區分“自動化操作”和“人工操作”，當我通過手動點擊完成驗證後，系統判定該環境為“合法人工使用”，從而解除了風險標記，後續即使使用Selenium訪問，也不會再觸發攔截。

核心經驗總結：遇到自動化工具被網站攔截時，不要侷限於技術層面的反檢測優化，不妨先通過手動訪問的方式完成網站的安全驗證，很多時候網站的風險標記是針對“環境”而非“工具”，人工驗證後即可解鎖工具的正常使用，這比複雜的技術配置更高效。