一、前言：爬虫突然“罢工”的突发状况
最近笔者在做一个开源项目分析的小工具，核心需求是通过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（禁用自动化控制特征）等参数，同时关闭了浏览器的扩展程序和预加载功能，代码片段如下：
fromseleniumimportwebdriverfromselenium.webdriver.edge.optionsimportOptions 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的反爬机制采用了“环境风险标记+人工验证解锁”的逻辑：
最初由于爬虫的高频访问，我的浏览器环境（可能关联了Cookie、浏览器指纹等信息）被Gitee标记为“高风险”，无论后续是通过Selenium还是自动化工具访问，都会触发强制安全验证。
Gitee的安全验证机制能够区分“自动化操作”和“人工操作”，当我通过手动点击完成验证后，系统判定该环境为“合法人工使用”，从而解除了风险标记，后续即使使用Selenium访问，也不会再触发拦截。
核心经验总结：遇到自动化工具被网站拦截时，不要局限于技术层面的反检测优化，不妨先通过手动访问的方式完成网站的安全验证，很多时候网站的风险标记是针对“环境”而非“工具”，人工验证后即可解锁工具的正常使用，这比复杂的技术配置更高效。
