SSL_ERROR_RX_RECORD_TOO_LONG 怎么解决
该错误常见于"HTTPS 请求打到了说 HTTP 的端口"——服务器 SSL 配置错位。检查 443 端口是否真的开了 SSL、VirtualHost 的 SSLEngine、以及是否有非 SSL 服务占用了 443。
一句话回答：这个错误的经典含义是客户端用 TLS 握手，服务器却在说明文 HTTP**（或反过来）——SSL 记录解析直接失败。最常见的原因：Apache/Nginx 的 443 端口 VirtualHost 里没开 SSL（漏了 SSLEngine on 或 listen 443 ssl）、HTTP 服务监听了 443、或代理把明文流量转发到了 HTTPS 端口。逐层确认"443 上跑的到底是不是 TLS"即可定位。**
排查步骤
1. 确认 443 端口在说什么
# 直接对 IP 发起 TLS 握手
openssl s_client -connect 域名:443 -servername 域名
# 明文 HTTP 提示协议错位；立即断开还可能是策略或协议等其他原因
用 curl 交叉验证：
curl -v http://域名:443/ # 检查是否正常提供明文业务；HTTPS 服务也可能对明文请求返回 HTTP 400
2. Apache：检查 VirtualHost
<VirtualHost *:443>
ServerName example.com
SSLEngine on # ← 常见遗漏
SSLCertificateFile /etc/ssl/cert.crt
SSLCertificateKeyFile /etc/ssl/server.key
</VirtualHost>
确认 mod_ssl 已启用（a2enmod ssl），配置里 <VirtualHost *:443> 别错写成 *:80。
3. Nginx：检查 listen 指令
server {
listen 443 ssl; # ← 漏了 ssl 关键字就会报这个错
server_name example.com;
ssl_certificate /etc/ssl/cert.crt;
ssl_certificate_key /etc/ssl/server.key;
}
4. 代理/端口转发层
前面有 LB/端口转发时，确认"443 → 后端 80"的协议转换是 LB 终止 TLS（正常架构），而不是把 HTTPS 流量原样转给了后端的 HTTP 端口。
修复监听协议后，分别验证端口连接和 HTTPS 请求。观测云 TCP 拨测与 HTTP 拨测可分别检查这两个环节；TCP 正常而 HTTPS 失败时，继续检查证书、协议及反向代理配置，不能单凭该组合就判定服务返回了明文。
其他可能
- 非标准 HTTPS 端口（如 8443）被当成 443 访问
- 同一 IP 上两个站点共用 443 但只有一套 SSL 配置（SNI 时代应以 server_name 区分，参考多域名配置）
- NAT/端口映射把 443 转到错误服务；普通安全组只过滤流量，不转发端口
常见问题（FAQ）
Q：只有 Firefox 报这个错，Chrome 报别的？
A：各家对同一问题的报错文案不同：Firefox 是 SSL_ERROR_RX_RECORD_TOO_LONG，Chrome 多为 ERR_SSL_PROTOCOL_ERROR。同一根因，按本文排查即可。
Q：改完配置还报同样的错？
A：nginx -t/apachectl configtest 通过后 reload；有 CDN/LB 的话检查边缘节点配置；浏览器清缓存或换无痕窗口重试。
Q：自签证书会导致这个错吗？
A：不会。自签证书报的是"证书不受信任"（AUTHORITY_INVALID）；RECORD_TOO_LONG 是协议层错位，与证书内容无关。
参考资料
本文依据官方资料核对，未进行现场运行测试；代码与配置示例需结合实际版本、权限和环境验证。
- nginx.org：configuring https servers
- httpd.apache.org：mod ssl
- docs.guance.com：tcp
- docs.guance.com：http
- docs.guance.com：synthetic test detection
