SSL_ERROR_RX_RECORD_TOO_LONG 怎么解决
该错误常见于"HTTPS 请求打到了说 HTTP 的端口"——服务器 SSL 配置错位。检查 443 端口是否真的开了 SSL、VirtualHost 的 SSLEngine、以及是否有非 SSL 服务占用了 443。
一句话回答：这个错误常见于客户端用 TLS 握手，端口却返回明文 HTTP，导致 TLS 记录解析失败；仅凭错误名称不能排除其他异常响应。最常见的原因：Apache/Nginx 的 443 端口 VirtualHost 里没开 SSL（漏了 SSLEngine on 或 listen 443 ssl）、HTTP 服务监听了 443、或代理把明文流量转发到了 HTTPS 端口。逐层确认"443 上跑的到底是不是 TLS"，再结合代理和握手结果定位。
排查步骤
1. 确认 443 端口在说什么
# 对目标域名发起 TLS 握手，并发送对应 SNI
openssl s_client -connect 域名:443 -servername 域名
# 明文 HTTP 提示协议错位；立即断开还可能是策略或协议等其他原因
用 curl 交叉验证：
curl -v http://域名:443/ # 检查是否正常提供明文业务；HTTPS 服务也可能对明文请求返回 HTTP 400
2. Apache：检查 VirtualHost
<VirtualHost *:443>
ServerName example.com
# 启用 TLS
SSLEngine on
SSLCertificateFile /etc/ssl/cert.crt
SSLCertificateKeyFile /etc/ssl/server.key
</VirtualHost>
确认 mod_ssl 已启用（Debian/Ubuntu 可用 a2enmod ssl），同时存在合适的 Listen 443。用 apachectl -M 和 apachectl -S 检查模块及虚拟主机，配置里 <VirtualHost *:443> 别错写成 *:80。
3. Nginx：检查 listen 指令
server {
listen 443 ssl; # 启用 TLS；缺失时可能出现协议错误
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 的话检查边缘节点配置；继续核对 DNS、实际访问节点和 TLS 握手结果；清除浏览器缓存不能修复服务器协议错位。
Q：自签证书会导致这个错吗？
A：自签名本身通常导致证书信任错误，而非 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
