在運維圈子里，大家可能都遇到過這種奇怪的問題：

瀏覽器能打開 HTTP 網站，但一換成 HTTPS，頁面就死活打不開。

前段時間，我們就碰到這么一個典型案例。

故障現象

某公司系統在 VPN 隧道里訪問 HTTPS 服務，結果就是——打不開。HTTP 正常，HTTPS 全軍覆沒。

問題追蹤

乍一看，以為是證書、TLS 加密、瀏覽器兼容性這些問題。結果一層層排查下來，真正的罪魁禍首居然是：MTU（最大傳輸單元）。

原來：

■??正常情況下，鏈路 MTU=1500，TCP MSS=1460；

■??但由于數據要經過 IPSec 隧道，報文額外多了 52 字節封裝；

■??最終數據包=1512 字節，超過了 MTU；

■??偏偏 HTTPS 報文設置了 DF=1（禁止分片），所以一旦超出 MTU，報文直接被丟棄；

■??結果就是：HTTPS 握手直接掛掉。

HTTPS 為啥不分片？

因為 HTTPS 的核心是安全和完整性。TLS 協議要求傳輸的數據必須完整，一旦分片就有被截獲或篡改的風險，所以干脆一刀切：禁止分片。

這就導致——只要 MTU 出問題，HTTPS 就比 HTTP 更容易“翻車”。

解決方法

直接改設備?MTU/MSS

讓服務器和客戶端都用更小的報文，比如?1400。但設備多時不現實。

讓中間設備幫忙調整?MSS（最優解）

很多防火墻/路由器都有類似功能：在?TCP?握手時，把?MSS?改小，提前避免超?MTU。

■?思科的例子就是：ip tcp adjust-mss 1400

Linux 網關

也能用 iptables 干預 TCP MSS：

這個案例其實告訴我們：

■??HTTPS 故障，不一定是“證書問題”，可能是網絡層的 MTU 問題；

■??VPN/隧道場景下尤其常見；

■??最優雅的解決方案，是讓中間設備在握手階段就“幫忙改 MSS”，而不是等到業務掛掉才救火。

所以，下次再遇到 HTTPS 打不開，別急著罵瀏覽器，先想想是不是報文太大了！