问题标题可能没有涵盖整个主题，因为我做了很多研究并发现了一些奇怪的事情。
因此，首先，我要尝试实现的是某种代表用户工作的网站客户端(不做任何违法行为，只是优化用户的某些工作流程)。我已经为许多网站完成了此操作，并且效果很好。但是，对于当前版本，存在一个问题。
通常，如果遇到验证码，我只会打开一个嵌入式 Chrome 窗口供用户传递。但是，对于我正在谈论的网站，它没有帮助，因为验证码没有显示在浏览器中，而是在我模仿请求浏览器准确发送时发送给我。
因此，我尝试调查 Chrome 发送的请求与我使用 Fiddler 的应用程序发送的请求之间的区别。 但是，如果我启用 Fiddler，即使是真正的 Chrome 发送的请求也会面临相同的验证码。
我已经在 Chrome 中禁用了 HTTP/2、SPDY 和 IPv6，因为我认为这可能是不同之处。它没有帮助。我试过使用 Chrome 开发工具比较 Chrome 发送的请求——没有区别，它们都使用 HTTP/1.1，都有完全相同的 header ，完全相同的 cookie(或者没有 cookie，没有区别) .但每当我启用 Fiddler - 网站都会以验证码响应。
这是我第一次遇到这样的事情，我几乎准备好用头撞墙了，因为我看不到任何可能的方式让网站了解请求正在由 Fiddler 代理因为它没有添加任何自定义 header 或其他内容。
除非该网站以某种方式检测到正在设置 HTTPS 连接的确切方式，这听起来很疯狂……这应该是不可能的。
寻求有关如何进一步调试的建议。
更新:
我没有找到解决方案，也不了解相关网站如何检测来自 Chrome 的直接连接，但设法找到了解决方法:
我正在使用我的代码从网站接收到的验证码获取页面，并将 CEF 接收到的实际页面动态替换为该验证码页面，从而允许用户传递它。
因为它没有回答原始问题，所以我不会将其作为答案发布，并将让这个问题悬而未决。
最佳答案
网站本身通常不会检测到任何内容。验证码通常由 Cloudflare 等反 DOS 保护服务提供商提供。
根据我的经验，此类系统通过 JavaScript 将浏览器指纹识别系统(获取使用的 Web 浏览器名称、版本和使用的操作系统)与 HTTPS (TLS) 级别的检测相结合:
在 TLS 协议(protocol)握手中，客户端发送一条 CLIENT_HELLLO 消息，其中包含有关受支持的 TLS 版本和密码套件的信息，以及某些 TLS 扩展中的其他附加数据(例如，如果它支持 HTTP/2)。
这次握手可以再次被指纹识别。例如，如果您现在通过 Fiddler 使用 Firefox，则浏览器指纹显示 Firefox，但 Fiddler 是一个 .Net 应用程序，因此指纹表明使用了 Windows schannel TLS 库。两个指纹都不匹配，因此保护系统会将您重定向到验证码对话框。
关于http - 如何防止网站检测到 Fiddler，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62133226/