http和https最直接的区别是:http明文传输,https在传输层加上TLS加密与身份校验。判断“正常还是异常”,不能只看地址栏有没有小锁,而要看三件事是否同时成立:浏览器对证书链的校验通过、页面全部子资源都走https、以及服务器把http请求正确跳转到https。三者缺一,就可能出现“看起来是https、实际仍有异常”的结果。
http把请求和响应内容直接交给网络传输,路径上的代理、网关或同一网络中的其他设备都可能读取甚至篡改内容。https在http之下增加TLS握手:客户端先验证服务器证书是否由受信任的证书颁发机构签发、域名是否匹配、是否在有效期内,然后协商出会话密钥,之后的正文才加密传输。代价是首次连接多一到两次往返的握手时间,以及证书的申请与续期成本;现代硬件和会话复用可以把这个代价压得很低,所以“为了性能而不上https”通常不是合理理由。
需要分清的是:https解决的是传输机密性、完整性和服务器身份真实性,它不保证网站代码没有漏洞、不保证后台不被撞库、也不保证搜索引擎一定给更好排名。把https当成“安全认证”或“排名保证”都是过度解读。
http://开头的域名,最终地址变成https://,且状态码是301或308这类永久跳转,而不是200直接返回一份http页面。http://开头的混合内容;控制台没有“Mixed Content”警告。这三条同时成立,才可以判定为“正常”。只满足第一条,可能是跳转到了https但页面里仍加载http图片或脚本;只满足第二条,可能是证书有效但跳转缺失,用户仍能用http访问到内容。
异常不等于“打不开”,很多异常是静默的。以下现象各自可能对应多种原因,需要逐项排查,不要一看到红色警告就断定是证书过期。
www却访问裸域)、中间证书缺失,也可能是客户端时间错误或企业代理替换了证书。前三种是服务端问题,最后一种与站点无关。curl -I http://example.com,看返回的Location是否指向https,再对https地址执行一次,确认最终状态码为200。openssl s_client -connect example.com:443 -servername example.com,确认输出中包含完整的证书链且验证结果为Verify return code: 0 (ok)。www和不带www的域名各测一次,确认两者都能正确跳转且证书覆盖对应域名。这套检查适用于多人协作交付:把上述四条结果作为验收项写进交付说明,谁改动了跳转规则或证书配置,都能用同一组命令复现结论,减少“我这边正常”的扯皮。如果站点通过CDN或反向代理提供服务,还要在代理层再测一次,因为源站正常不代表边缘节点配置一致。
https配置正确,只说明传输层正常,不代表页面会被收录。robots.txt里的Disallow只是抓取限制,不是可靠的索引移除手段;提交站点地图也不保证收录。如果发现https页面没有被索引,应先确认是否被robots.txt屏蔽、是否返回了noindex、以及http与https是否产生了重复内容,而不是把问题归到协议本身。
下一步:挑一个你负责的域名,按上面的四条检查跑一遍,把结果记成一份可复用的验收清单,再决定是修跳转、补证书链,还是清理页面内的http资源。