快訊
Windows 顯示「沒有安裝音訊輸出裝置」?音效服務與驅動完整修復機械鍵盤軸體怎麼選?紅軸、茶軸、青軸與靜音軸的手感與適用場合比較Windows 服務 Error 1068 怎麼查?從事件 7001 追出真正失敗的相依服務Ping TTL 欄位是什麼?為什麼 Windows 是 128、Linux 是 64Windows hosts 檔案教學:DNS 前先查誰?封鎖與測試網站實作ChatGPT for Excel 怎麼用?安裝增益集、在試算表裡請 AI 分析與改公式
2026-10-15
MTU 與封包碎片示意封面,說明部分網站打不開的路徑 MTU 問題
科技大小事

有些網站開得了、有些死都打不開?MTU 與封包碎片的隱形問題

約 10 分鐘閱讀 · 36 次瀏覽
作者:
廣告
內容目錄 顯示

⚡ 站長快讀:核心重點

  • 文章屬性:科技冷知識 / 網路規格解析
  • 核心結論:先別急著改 MTU——該先查的是路徑上哪一段把 ICMP 擋掉了;本文帶你用 ping 量出這條路徑真正的上限,再決定要不要動設定。
  • 適用對象:遇過「別人都正常、只有某幾個網站打不開」的人

📌 快速答案

一句話答案:MTU 與封包碎片決定單一封包的上限;路徑上最小的 MTU 塞不下、又收不到 ICMP 通知時,大封包會被靜靜丟掉,造成部分網站永遠打不開。

🔍 故事的起點

先講結論:這種「有些網站開得了、有些死都打不開」的怪毛病,問題常常不在網路慢,而在某個尺寸以上的封包整批消失。徵狀很好認——首頁秒開,但換到某個站就永遠轉圈;純文字頁面正常,一遇到大圖或登入頁就卡死;換瀏覽器、換 DNS、重開機通通沒用,改用手機熱點卻又好了(因為換了一條路徑,路徑上最小的那一段也跟著換掉)。

這篇要把三件事講清楚:第一,問題往往不是 MTU 設錯,而是 ICMP 被防火牆擋掉、讓自動協商機制整個失效;第二,1500、1492、1280、68 這些數字各自出自哪一份規範、怎麼推導出來的,而不是背口訣;第三,ping 指令那個「要減 28」的公式到底減的是什麼。另外提醒一句:這種只影響部分目標的症狀,跟整條線路都慢的〈網速 1G 卻感覺像撥接?修改 DNS 與解決 Bufferbloat 的網路延遲最佳化術〉是兩回事,別拿延遲的解法來治打不開。

🧪 原理拆解

MTU 是什麼:一節車廂能塞多少貨

MTU(Maximum Transmission Unit,最大傳輸單元)是一條鏈路單次能載運的最大封包大小。它不是頻寬、不是速度,而是「單件貨物的尺寸上限」——就像貨運電梯有高度限制,再大的貨得拆成幾趟,拆不了就上不去。

一般家用與辦公室的乙太網路,這個上限是 1500 位元組。PPPoE 那份文件裡就直接引述了這個前提:「Ethernet 有 1500 位元組的最大酬載」。往下還有兩個常被引用的底線:任何一台 IPv4 裝置都必須能轉送 68 位元組的資料包而不再分片(這就是 IPv4 最低 MTU 的由來),而每一台 IPv4 主機都必須有能力接收 576 位元組的資料包(不論是整包到還是分片後重組)。

MTU 關鍵數值對照:乙太網路 1500、PPPoE 1492 為上限,IPv6 最低鏈路 1280、IPv4 最低 68 位元組為下限

封包碎片:IPv4 會切,IPv6 不切

當一個資料包比下一段鏈路的 MTU 還大,IPv4 的做法是在中途的路由器把它切成碎片,而重組只在目的端主機進行。這代表兩件事:中途每切一次都要重算表頭、吃掉路由器的 CPU;而且只要任何一片在路上掉了,整個原始資料包就全毀,得整份重傳。

IPv6 乾脆把這條路封死了。規範明文寫著:與 IPv4 不同,IPv6 的分片只由來源端執行,路徑上的路由器不做分片。同一份規範也定下 IPv6 的最低鏈路 MTU 為 1280 位元組,任何一條鏈路都必須撐得住這個尺寸。少了「路由器幫你救」這層保險,IPv6 更依賴下面要講的協商機制。

廣告

DF 旗標與路徑 MTU 探索:網路自己談出最大值

IPv4 表頭裡有一個 DF(Don’t Fragment)旗標:設為 1 就是「不准切我」。路由器如果遇到太大又標了 DF 的資料包,規範要求它直接丟棄,然後回一封 ICMP 訊息說「需要分片但 DF 已設」。

路徑 MTU 探索(Path MTU Discovery)就是拿這個特性來玩的:來源端先假設路徑 MTU 等於自己第一段鏈路的 MTU,所有封包都標上 DF 送出去;哪一段塞不下,那台路由器就回一封 ICMP Destination Unreachable(Type 3、Code 4),並把自己下一段的 MTU 寫進訊息裡,來源端照著往下調。規範同時要求:主機永遠不得把路徑 MTU 估值降到 68 位元組以下。

黑洞:ICMP 被擋掉的那一刻

重點來了。整套機制完全靠那封 ICMP 訊息活著。如果路徑上某台防火牆或路由器為了「安全」把 ICMP 一律丟棄,大封包會被丟掉,卻沒有人來通知來源端;來源端以為封包還在路上,傻傻地重傳、重傳、再重傳,每一次都一樣大、一樣被丟。這就是俗稱的 PMTUD 黑洞。

於是症狀變得非常古怪:交握封包很小,能過,所以連線「建立成功」;小網頁裝得進小封包,正常顯示;一旦要傳大圖、大表單或登入回應,封包一變大就進黑洞,畫面停在轉圈。同一台電腦、同一條線,有些站好好的、有些站永遠打不開,根源就在這裡。也因為這樣,正解常常不是「改你家的 MTU」,而是「找出哪一段把 ICMP 吃掉了」。

PPPoE 的 1492:一道看得懂的減法

如果你的連線是走 PPPoE 撥接,上限還會再低一點。PPPoE 那份文件把數字算得很清楚:乙太網路酬載 1500 位元組,PPPoE 表頭吃掉 6 位元組、PPP 協定識別碼再吃 2 位元組,所以 PPP 的 MTU 不得大於 1492。

1500 減 8 等於 1492——這個 8 不是誰拍腦袋定的,是兩個表頭加起來的實際大小。VPN 與各種隧道封裝也是同樣的邏輯:每包一層就少幾十個位元組,能用的空間越疊越小。懂了這個減法,1492、1452、1400 這些數字就不再是玄學。

廣告

自己量一次:ping 的「減 28」從哪來

Windows 內建的 ping 就能量。本段與下一段的指令,都在命令提示字元(cmd)或 PowerShell 視窗裡輸入;這一條只是查詢,一般使用者權限就夠。兩個參數是關鍵:/f 會把 DF 旗標設為 1(僅 IPv4 可用),官方說明直接寫著這個參數就是用來排查路徑 MTU 問題的;/l 指定的是資料欄位的長度,預設 32 位元組。官方 ping 說明頁標示的適用範圍含 Windows 11 與 Windows 10。

ping /f /l 1472 8.8.8.8

成功就代表這條路徑吃得下 1500。為什麼是 1472 而不是 1500?因為 /l 只算資料,外面還要包兩層表頭:IPv4 表頭 20 位元組 + ICMP Echo 表頭 8 位元組 = 28 位元組(ICMP Echo 的 8 位元組是型別 1 + 代碼 1 + 檢查碼 2 + 識別碼 2 + 序號 2)。1472 + 28 = 1500,剛好卡滿。

失敗時會出現「需要分割封包但 DF 旗標已設定」意思的錯誤訊息(實際字串依系統語言而異),這時往下二分搜尋即可:試 1440、1400、1300⋯⋯找到最大的成功值,再加 28,就是這條路徑真正的 MTU。

動手改之前:回退與停止條件

先確認再動手。 下面兩條是 netsh 的 IPv4 情境寫法;查詢那條一般權限即可,修改那條必須「以系統管理員身分執行」的命令提示字元才跑得動,權限不足會直接失敗。另外提醒:本文參考的那份 Microsoft 指令說明是封存版頁面,頁內把情境前綴寫成 netsh interface ip,和下面的 netsh interface ipv4 是同一組指令的兩種寫法,對照文件時不必以為自己打錯。

先查目前值(這一步同時也是你的原值備份):

netsh interface ipv4 show subinterfaces

指令能正常列出你的網路卡,才代表這套寫法在你的系統可用;列不出來就別往下做。確認沒問題再改:

廣告
netsh interface ipv4 set subinterface "乙太網路" mtu=1400 store=persistent

介面名稱請換成你自己那張網路卡在「網路連線」裡顯示的名字。官方文件在 set subinterface 這一節標明:mtu 的預設值就是該鏈路的原生 MTU;而 store 這個參數,同一份文件在其他指令的說明裡寫得最清楚——變更只到下次開機為止(active),或是永久保留(persistent)。

  • 🔙 回退步驟:改之前先跑一次 show subinterfaces 把原本的數字抄下來或截圖存檔,要還原就用同一條指令把 mtu= 填回原值。若當初用的是 store=active,重新開機即自動失效。
  • 停止條件(符合任一請先別動):不確定自己是哪一張網路卡、沒抄下原始數值、這台是公司或學校管控的設備而沒有資訊人員授權、或是指令輸出跟本文描述對不上——請停下來問人,別亂試。
  • 改小 MTU 是止血、不是治本:它只是讓封包小到不需要分片,真正塞住的那一段、被吃掉的那些 ICMP 依然在。自己家的線路這樣做沒問題;企業網路的正解是請網管在網路設備上處理(TCP 連線在交握時本來就會互相宣告各自的分段大小上限,規範也要求送出端不得超過對方宣告的值),而不是叫每台電腦自己改。

💡 總結:冷知識延伸

站長我的看法是:MTU 這題之所以難纏,不在於多深奧,而在於它壞得太安靜。多數網路故障至少會給你一個錯誤碼或逾時訊息,有東西可以拿去搜尋;MTU 黑洞什麼都不給,只給一個轉不完的圈,還附贈「別的網站都好好的」這條假線索,把人引去重灌系統、換路由器、罵電信業者。

再送一個延伸的冷知識:路徑 MTU 是會變的。網路繞路換了一條線,最小的那段就跟著換,所以規範允許主機偶爾把估值往上試探,但硬性要求兩次試探之間不能太密——因為每次試探失敗都得丟封包。說穿了就是一場「猜大了會痛、猜小了會虧」的反覆試探,而這場試探能不能進行,全繫於那封小小的 ICMP 有沒有被放行。下次再看到有人主張「ICMP 全部擋掉最安全」,你就知道代價是什麼了。

❓ 常見問題

Q:MTU 調小一點是不是比較保險?

會保險,但要付代價。MTU 越小,同樣的資料要切成越多包,表頭的固定開銷佔比越高,吞吐量就越差。沒有症狀就別動,原生值本來就是最適合那條鏈路的設定。

Q:怎麼分辨是 MTU 問題還是網站自己壞了?

看選擇性。換個網路(例如手機熱點)如果同一個網站就正常,而且症狀是「連得上但載不完」而非「完全連不上」,那 MTU 的嫌疑就很大;若換網路一樣打不開,那多半是對方的問題。

Q:為什麼 IPv6 反而更容易踩到?

因為 IPv6 的路由器不幫你分片,大小不合就是直接丟,完全依賴路徑 MTU 探索。一旦路上的 ICMPv6 被過濾掉,這套機制就失去回饋來源,大封包同樣會進黑洞。

Q:1492 這個數字一定是 PPPoE 嗎?

不一定,但高度相關。PPPoE 的 6 + 2 位元組表頭讓上限剛好落在 1492;其他隧道技術也會各自吃掉不同的位元組數,算出來是別的數字。重點是理解「1500 減掉封裝層」這個減法,而不是死背某一個值。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|RFC 規範文件與作業系統官方:

⚠️ 本文核心事實以第一級規範原文為準;內容屬規範查證與機制解析,非站長第一手實測。

📅 本文查證戳記:2026-09-21 撰寫。指令語法取自 Microsoft 官方 ping 指令參考與 netsh IPv4 指令參考(後者為封存版頁面),協定數字取自 RFC 原文;若你在自己的系統上遇到差異,歡迎在留言區回報。

廣告