Selenium+Selenium Wire访问AWS/GCP遇SSL握手错误及生产环境疑问

一、自定义openssl.cnf配置生效的原因 #

Selenium Wire作为HTTP代理，会拦截并解密浏览器的HTTPS请求，这个过程完全依赖OpenSSL库处理TLS握手逻辑。AWS和GCP的云门户对TLS连接的安全性校验极为严格，默认的OpenSSL配置大概率存在以下问题：

• 包含了云门户禁用的弱加密套件（如旧版RC4、3DES类套件）
• 默认TLS版本过低（比如仅支持TLS 1.0/1.1，而云门户要求强制使用TLS 1.2及以上版本）
• 缺少某些必需的TLS扩展或证书验证规则

你添加的自定义openssl.cnf应该针对性调整了这些参数：比如强制启用TLS 1.2/1.3、仅保留云门户兼容的强加密套件、修正证书验证逻辑，让Selenium Wire的代理能和云门户服务器完成正常的TLS握手，进而成功加载页面内容——之前的空白页面本质是TLS握手失败导致的请求中断。

另外补充：undetected-chromedriver主要解决浏览器指纹检测问题，但你的情况核心是代理层的TLS兼容性故障，所以这个方案无效，而调整OpenSSL配置直接修复了代理的HTTPS处理能力。

二、确保AWS Lambda生产环境不复发的方案 #

Lambda的运行环境是Amazon Linux（或Amazon Linux 2），需要让Selenium Wire能正确加载你的自定义OpenSSL配置，具体操作如下：

1. 打包配置文件：将自定义的openssl.cnf和你的Lambda代码、依赖包（Selenium、Selenium Wire、ChromeDriver等）一起打包成部署包。
2. 设置环境变量：在Lambda函数的环境变量中添加OPENSSL_CONF，值为配置文件在Lambda中的绝对路径（比如/var/task/openssl.cnf，Lambda代码默认解压到/var/task/目录）。
3. 验证环境兼容性：
   • 确认Lambda使用的Amazon Linux版本的OpenSSL支持你配置中的参数（可通过在Lambda中执行openssl version -a查看版本及默认配置）。
   • 保证ChromeDriver和浏览器版本与本地测试环境完全一致，避免因环境差异导致TLS行为变化。
4. 日志排查机制：在Lambda代码中添加日志输出，记录Selenium Wire的代理运行日志（尤其是TLS握手相关信息），如果再次出现空白页面，可通过CloudWatch日志定位是否是配置未加载或握手失败。
5. 用Lambda层管理依赖：把OpenSSL配置、Selenium相关依赖打包成Lambda层，这样多个函数可以复用，后续更新配置或依赖版本也更方便。

内容的提问来源于stack exchange，提问作者Manspof