出现SSL_ERROR_RX_RECORD_TOO_LONG错误通常是因为服务器返回的HTTP响应被错误地当作HTTPS处理，或者SSL证书配置存在冲突，最直接有效的解决方法是检查Nginx或Apache配置中的端口监听与协议匹配，确保HTTP流量不被强制重定向到SSL端口。
这个错误代码在浏览器地址栏表现为红色的警告页面,它并不是说你的网站数据被窃取了，而是浏览器和服务器在“握手”时发生了严重的沟通误会，浏览器试图通过加密通道（HTTPS）发送请求，但服务器端却用明文通道（HTTP）或者错误的端口回应，导致数据包长度超出了SSL/TLS协议的预期限制，从而触发了“记录过长”的错误，解决这个问题的核心逻辑非常清晰：切断HTTP与HTTPS在端口层面的混淆，确保流量流向正确的处理程序。
排查Nginx服务器配置中的端口冲突
Nginx是目前国内中小型企业和个人站长使用率极高的Web服务器软件,绝大多数此类错误都源于其配置文件中的逻辑漏洞，当你在配置文件中同时监听了80端口和443端口，却错误地将80端口的请求强行重定向到443端口，或者在SSL模块中启用了非SSL的监听器时，就会引发此问题。
检查listen指令的协议标识
你需要打开Nginx的主配置文件,通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/目录下的.conf文件中，仔细查找所有包含listen指令的代码块。
- 正确做法：HTTPS监听必须明确标注
ssl参数。listen 443 ssl;。 - 错误做法：如果看到
listen 443;而没有ssl关键字，或者在listen 80;的代码块中包含了SSL证书路径指令，这往往是罪魁祸首。
业内专家指出,许多新手站长在配置Let’s Encrypt免费证书时，容易忽略HTTP到HTTPS的重定向逻辑，如果在80端口的server块中直接返回301重定向到443，但服务器并未正确加载SSL模块，浏览器就会尝试用HTTPS协议访问一个非SSL端口，进而报错。
验证重定向逻辑的正确性
为了确保流量正确流转,建议采用标准的重定向策略，对于所有通过80端口进入的HTTP请求，应统一重定向到对应的HTTPS URL。
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# 其他配置...
}
这种结构能确保浏览器先通过HTTP收到重定向指令,然后重新发起HTTPS请求，从而避开SSL握手阶段的错误。
Apache服务器中的SSL模块与端口映射问题
如果你使用的是Apache服务器,解决思路与Nginx类似，但配置语法不同，Apache的错误往往出现在mod_ssl模块未正确加载，或者虚拟主机（VirtualHost）配置中端口与协议不匹配。
确认mod_ssl模块已启用
在Debian或Ubuntu系统中,你可以使用以下命令检查并启用SSL模块：
sudo a2enmod ssl sudo systemctl restart apache2
在CentOS或RHEL系统中,确保httpd-mod_ssl包已安装，并在配置文件中确认LoadModule ssl_module modules/mod_ssl.so这一行未被注释。
修正VirtualHost配置
Apache的虚拟主机配置必须严格区分端口,一个常见的错误是在同一个<VirtualHost>标签中既处理80端口又处理443端口，且未正确分离SSL配置。
- 分离配置：为80端口和443端口分别创建独立的
<VirtualHost>块。 - 端口指定：在
<VirtualHost :443>块中，必须包含SSLEngine on指令，并正确指向证书文件路径。
据统计,相当一部分Apache服务器报错是因为管理员在复制粘贴配置时，遗漏了SSLEngine on这一关键指令，导致Apache误以为该端口不需要SSL加密，从而在接收到加密数据时解析失败。
CDN与负载均衡器的中间人干扰
如果你的网站使用了Cloudflare、阿里云CDN或AWS ELB等中间件，问题可能不出在源站服务器，而出在边缘节点与源站之间的通信协议上。
检查源站协议设置
在CDN控制台中,通常有一个“源站协议”或“回源协议”的选项，如果设置为“HTTPS”，但你的源站并未正确配置SSL证书，或者源站只监听80端口，CDN节点在向源站请求内容时就会发生SSL握手错误。
- 场景描述：用户访问
https://www.example.com，CDN节点成功建立SSL连接，但当它向源站请求数据时，源站返回的是HTTP明文数据，CDN节点试图将HTTP数据包装在SSL信封中返回给用户，导致数据包结构异常，浏览器报错。 - 解决方案：将CDN的回源协议设置为“HTTP”，或者确保源站正确配置了自签名证书供CDN回源使用。
负载均衡器的SSL卸载
在使用负载均衡器（SLB/ELB）时，如果开启了SSL卸载功能，负载均衡器负责终止SSL连接，然后将明文HTTP请求转发给后端服务器，如果后端服务器错误地配置了SSL监听，或者负载均衡器的健康检查使用了HTTPS协议但后端未开启SSL，也会导致此类错误。
- 操作路径：登录云控制台，找到负载均衡实例，检查监听规则，确保前端监听使用HTTPS，后端服务器组监听使用HTTP。
浏览器缓存与DNS解析的隐性干扰
服务器配置完全正确,但错误依然出现，这通常是因为浏览器缓存了旧的错误状态，或者DNS解析指向了错误的IP地址。
清除浏览器缓存与强制刷新
在排查服务器配置之前,先尝试在浏览器中按Ctrl + Shift + Delete清除缓存和Cookie，或使用Ctrl + F5强制刷新页面，如果错误消失，说明只是本地缓存问题。
检查DNS解析记录
使用nslookup或dig命令检查域名解析是否指向了正确的服务器IP。
nslookup example.com
如果解析结果指向了一个未配置SSL的备用服务器IP,或者指向了错误的地区节点，也会导致连接失败，确保A记录或CNAME记录指向了正确的、已配置SSL证书的主服务器。
常见问题解答：SSL_ERROR_RX_RECORD_TOO_LONG
为什么更换SSL证书后仍然出现此错误？
更换证书后出现此错误,通常是因为新证书的私钥与公钥不匹配，或者证书链不完整，更常见的原因是配置文件中仍然引用了旧证书的路径，或者服务器未重启以加载新配置，建议先使用openssl x509 -in cert.pem -text -noout命令验证证书有效性，然后重启Web服务。
使用HTTP/2协议会加剧这个问题吗？
HTTP/2协议强制要求使用HTTPS，因此如果服务器配置错误，启用HTTP/2会立即暴露问题，HTTP/2的多路复用机制对TLS握手的依赖性更强，一旦握手失败，整个连接会迅速中断并报错，在启用HTTP/2之前，务必确保TLS握手完全正常。
本地开发环境出现此错误如何快速修复？
在本地开发环境中,如果使用了反向代理（如Nginx或Apache）模拟生产环境，错误通常源于代理配置中的proxy_pass指令使用了https://但后端服务未开启SSL，修复方法是将proxy_pass改为http://，或者在后端服务中启用自签名SSL，对于前端开发者，可以直接在浏览器地址栏输入http://localhost访问，避开HTTPS验证。
解决SSL_ERROR_RX_RECORD_TOO_LONG错误的关键在于理清流量路径,确保每个环节的协议匹配，从Nginx和Apache的配置检查，到CDN和负载均衡器的设置，再到本地环境的调试，每一步都需要严谨的逻辑验证，只要遵循协议规范，确保HTTP与HTTPS在端口和模块上的严格分离，这一错误即可彻底消除。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/ssl_error_rx_record_too_long%e6%80%8e%e4%b9%88%e8%a7%a3%e5%86%b3%ef%bc%9fssl%e8%af%81%e4%b9%a6%e9%85%8d%e7%bd%ae%e9%94%99%e8%af%af%e5%af%bc%e8%87%b4/
