移动端真机断连:服务器兼容性陷阱揭秘
|
去年6月12号下午三点零七分,iPhone 12真机连着Charles,刚切到公司WiFi,首页请求发出去就卡在Pending——不是超时,是直接断开重连,三次全灭。控制台里连个ERR_CONNECTION_RESET都没出来,只有Network面板里那个灰掉的status列写着“failed”,右键复制响应体,空的。我盯着它看了四十七秒,背后椅子被谁蹭了一下,哐当一声,键盘上Q键早掉了,只剩个塑料茬儿杵在那儿。 亲历现场。不是测试环境飘红,不是CI挂了,是运营在会议室白板上用红笔圈出“今晚八点上线”的字还没擦干净,我手机还在连着数据线,页面已经白屏三秒后自动跳转到错误页。白板右下角还留着上周遗留的“H5需兼容iOS 14.5+”字样,墨迹晕开了,像干掉的血渍。有人端着杯子站了很久,水汽在杯壁凝成一道斜线,没动,也没说话。 问题复盘?不。这压根不是前端能复盘出来的——你本地dev server跑得好好的,mock接口丝滑得像德芙,build之后扔CDN,安卓、模拟器、iOS模拟器全过,连Safari Web Inspector都抓不到异常帧。唯独两台真机:一台iPhone XR(系统15.6),一台iPad mini 6(16.1),点开URL,首屏转圈、按钮点了没反应、控制台一片红——红得特别安静,没报错,只有fetch promise一直pending,最后静默reject。连console.timeEnd都来不及打点。 跟后端吵了两次。第一次他甩来一个curl命令,说“你看,我这儿全通”。我当着他面拿同一台iPhone扫二维码打开,curl回显200,我页面network卡死。他低头看手机壳上印的“DevOps”贴纸,抠了一下边角,没再吭声。第二次我拖着他进会议室,投屏,手机架在支架上,Chrome DevTools连着Mac,Network里那个GET /api/config的请求,Status列从pending突然变成红色叉,然后消失。他凑近看,说:“你TLS版本是不是太低?”我翻出构建日志最后一行:webpack 5.88.2 + @vue/cli 5.0.8 ——跟他服务器用的OpenSSL 1.1.1w毛关系没有。他端起杯子又放回去,水洒了一点在桌上,没人去擦。 问题在哪?就在那台部署用的CentOS 7.9机器上。不是nginx配置漏了HTTP/2,不是证书链没补全,是他们升级完内核后顺手把ssldhparam.pem替成了新的——3072位DH key。iOS 15.0–15.4默认不认这个,但15.5+加了个fallback机制。我们测的真机是15.6,本该OK。可实际行为是:首次TCP握手成功,TLS协商时client hello里带了旧的supported_groups,server回的server hello却强行选了x25519——而iOS 15.6对这种混合协商会静默终止连接。这不是bug,是RFC 8446里的合法行为。但没人告诉你,Apple在WebKit里藏了个“检测到x25519+secp256r1混用且无ALPN fallback时,直接close socket”的开关。关得特别利索,连FIN都不发。 工位的显示器是竖着的,刚好把Network面板拉满。那天下午五点十七分,我在DevTools里反复切换“Preserve log”,抓到第19次失败时,看到TLS handshake那一栏下面多出一行灰色小字:“Cipher suite: TLS_AES_128_GCM_SHA256 (0x1301)”。正常啊。直到我把鼠标悬停上去,tooltip弹出“Key exchange: x25519 (0x001d) — used”。我截图发给后端,附了句:“你们nginx conf里ssl_ecdh_curve那行,删掉。”他回了个“???”,三分钟后,conf里那行没了。我reload,页面进了。没转圈,没报错,控制台干干净净。 外卖到了没人去拿,在茶水间门口塑料袋上印着“酸菜鱼·免辣”。我撕开包装盒的时候,手指沾了点汤汁,抹在键盘上,刚好盖住那个掉了Q键的位置。不是所有断连都叫“网络问题”。有些是协议层的冷枪,打中了你根本没加载进内存的RFC段落;有些是升级日志里一句轻飘飘的“optimization for modern clients”,结果把老设备踢出了协商队列;还有些是测试机型号选错了——我们一直用iPad mini 6做主力测机,因为它的GPU和Touch ID逻辑最接近日常用户,但它偏偏是第一批默认启用strict x25519协商的设备之一,而iPhone 12反而带了fallback兜底。
文章配图,仅供参考 无所谓。反正我已经把curl -v那条命令加进了每次上线前的手动checklist,第三步,写在便签纸上贴在显示器边框上,墨水有点洇:“curl -v --tlsv1.2 -k https://m.xxx.com/api/config | grep ‘Server’”。便签底下压着上次需求评审的设计稿标注,上面写着“按钮点击态:opacity 0.7,持续300ms”,没标active伪类适配。产品临时加的,说是“竞品都这样”。我没改。现在它还是透明的,真机上点下去,视觉反馈为零,但至少没断连。接下来两天,我把所有对外接口的curl调试语句存进一个本地gist,带注释说明哪几个会触发DH协商陷阱。没推PR,不走CR,就自己用。另外,明天借台iOS 14.8的iPad Air 3过来,插上,手动点一遍所有入口URL。Q键还是没装回去,反正左手拇指早就习惯盲打R了。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


移动端兼容性测试:90%应用折戟第三步
移动端埋点失效92%:3个兼容性盲区揭秘
一次架构升级,攻克90%移动端真机兼容断层
移动端模型性能水土不服?真机压测见真章