⚡ 站長快讀:核心重點
- 文章屬性:教學實戰
- 適用系統:Windows 11、Windows Server 2022 / 2025
- 難易度 / 耗時:中等 / 約 15 分鐘
- 核心結論:四種開法(robocopy 單次指定、對應磁碟機、共享、用戶端全域)照影響範圍由小到大依序試,先用 robocopy 量過有沒有效,再決定要不要往上開。
- 適用對象:在區域網路裡常傳大檔的 Windows 11 使用者、家用檔案伺服器與小型辦公室 IT
📌 快速答案
一句話答案:SMB 壓縮會在檔案送上網路前即時壓縮內容,只有在網路頻寬吃緊、而且檔案本身可壓縮率夠高的情況下,傳輸時間才會真的縮短。
🧰 開始前的準備
- 系統需求:兩端都要支援才會生效——兩台電腦都需要是 Windows 11(含)以上或 Windows Server 2022(含)以上,所以兩台 Windows 11 互傳也算數。壓縮是雙方協商出來的能力,只有一端支援不會啟用。另外,要用群組原則或 PowerShell 控制「一律壓縮 / 一律拒絕」,還需裝上 Windows Server 2022 的 KB5016693(OS Build 20348.946)或 Windows 11 的 KB5016691(OS Build 22000.918)以後的更新
- 權限需求:設定共享或用戶端全域設定需要系統管理員;只用
robocopy /compress則不需要 - 需要工具:Windows PowerShell、robocopy(皆為系統內建)
- 預計耗時:約 15 分鐘
- 難度門檻:看得懂一行 PowerShell 指令就能做
🔍 為什麼你需要這個?
在家裡或辦公室搬一個 40GB 的虛擬機硬碟檔到 NAS,眼睜睜看進度條爬十幾分鐘,是很多人共同的經驗。傳統做法是先用壓縮軟體把檔案打包成一包,傳完再到對面解開——多兩道工、多一份暫存空間,而且打包本身也要花時間。
SMB 壓縮要解決的就是這件事。微軟官方文件的說法是:它讓管理員、使用者或應用程式要求檔案在網路傳輸過程中被壓縮,省去「先手動壓縮、複製、再到目的端解壓縮」的流程;壓縮過的檔案佔用較少網路頻寬、傳輸時間也較短,代價是傳輸期間 CPU 使用率略為增加(官方事實,來源:Microsoft Learn《SMB Compression》)。
但這裡有個很多教學文不會講清楚的前提:它不是萬用加速鍵。同一份官方文件明白寫著,SMB 壓縮在頻寬較低的網路上最有效,例如用戶端的 1 Gbps 乙太網路或 Wi-Fi;而在一條沒有壅塞的 100 Gbps 網路、兩端又都是快閃儲存的情況下,實務上開不開壓縮可能一樣快——只是仍能替其他應用程式少製造一點壅塞(官方事實,同來源)。
換句話說,這篇的重點不只是「怎麼開」,而是「什麼時候開了才有意義」。
🛠️ 實戰步驟
步驟一:先確認兩端條件
SMB 壓縮適用於 Windows Server 2025、Windows Server 2022 與 Windows 11(官方事實,來源:Microsoft Learn《SMB Compression》)。要注意官方文件對「用戶端」與「伺服器」的定義:它指的是這次檔案傳輸中的角色,不是 Windows 版本或 SKU——Windows Server 2022 和 Windows 11 都可以當壓縮的用戶端或伺服器。所以兩台 Windows 11 互傳也在適用範圍內。
演算法方面,Windows 支援 XPRESS(LZ77)、XPRESS Huffman(LZ77+Huffman)、LZNT1 與 PATTERN_V1,官方文件載明自動使用 XPRESS(官方事實,來源:Microsoft Learn《SMB Compression》);另在 Windows 11 24H2 與 Windows Server 2025 起新增 LZ4,並由系統自動協商雙方都支援的最佳演算法(官方事實,來源:Microsoft Learn《SMB features in Windows and Windows Server》)。這代表你不需要、也沒有必要自己挑演算法。
先看一下本機用戶端目前的壓縮設定,用這行純查詢指令即可(不會改動任何設定):
# 查看目前 SMB 用戶端壓縮相關設定
Get-SmbClientConfiguration | Select-Object RequestCompression, DisableCompression這兩項要能用 PowerShell 或群組原則設定,需要 KB5016693(OS Build 20348.946)或 KB5016691(OS Build 22000.918)以後的版本。想確認屬性是否存在,可改跑 Get-SmbClientConfiguration | Format-List * 看完整清單;版本則用 winver 對照上面兩組 OS Build。版本不足時,後面用群組原則與全域設定的段落就不適用。
如果你連基本的共享都還沒設好,可以先看站長之前寫的 Win10/Win11 共享資料夾、共享硬碟詳細設定教學,把共享跑通再回來開壓縮。
步驟二:挑一種開啟方式
官方提供四條路,差別在「誰決定要壓縮」與「影響範圍多大」。建議從影響範圍最小的開始試。
方法 A|單次複製時指定(影響最小)
用 robocopy 加上 /COMPRESS 參數,只有這一次複製會要求壓縮:
ROBOCOPY C:\hypervdisks \\fs1\disks$ *.vhdx /COMPRESS方法 B|對應網路磁碟機時要求壓縮
適合寫進登入指令碼,或平常固定掛載某台伺服器的情境。指令會建立一個要求壓縮的對應磁碟機:
New-SmbMapping -LocalPath "Z:" -RemotePath "\\fs1\sales" -CompressNetworkTraffic $true方法 C|共享資料夾一律要求壓縮(伺服器端)
在伺服器上讓某個共享被連線時一律要求壓縮:
Set-SmbShare -Name "Sales" -CompressData $true新建共享時則是 New-SmbShare 搭配 -CompressData $true 參數。若你習慣圖形介面,官方文件也提供 Windows Admin Center 的路徑:檔案和檔案共用 → 檔案共用 → 編輯或新增共用 → 勾選 Compress data。
方法 D|用戶端一律要求壓縮(全域,影響最大)
這個設定會讓 SMB 用戶端即使伺服器或應用程式沒指定,也一律要求壓縮:
Set-SmbClientConfiguration -RequestCompression $true對應的群組原則位於 電腦設定\原則\系統管理範本\網路\Lanman Workstation,啟用「Use SMB Compression by Default」原則;伺服器端則在 Lanman Server 底下啟用「Request traffic compression for all shares」(官方事實,同來源)。
💡 為什麼要這樣做? 檔案總管本身沒有「這次要壓縮」的選項。官方文件明講:如果你想讓檔案總管、第三方複製工具或應用程式用到壓縮,途徑就是對應磁碟機時開壓縮、在共享上開壓縮,或把 SMB 用戶端設成一律壓縮——也就是方法 B、C、D 三選一。
⚠️ 這四個方法都是要求壓縮,不是保證。實際會不會壓、壓多少,取決於對端是否接受,以及檔案內容壓不壓得動。
步驟三:驗證壓縮真的生效
別憑感覺判斷。官方給的驗證法很直接:把同一個檔案用 robocopy 傳兩次,一次加 /compress、一次不加,中間把伺服器上的檔案刪掉。如果壓縮有作用,你會在工作管理員看到較低的網路使用率,以及較短的複製時間(官方事實,同來源)。
伺服器端還可以看效能監視器裡的「SMB Server Shares」物件,觀察 Compressed Requests/sec 與 Compressed Responses/sec 兩個計數器,直接確認有沒有壓縮流量。
官方也提醒了一個很容易誤判的測試環境:在同一台 Hyper-V 主機上的兩台虛擬機之間測試,可能看不出任何時間差,因為虛擬交換器是 10 Gbps 且沒有壅塞,加上現代 Hypervisor 常搭配快閃儲存。要測就在你真正要用的網路上測,或用 Set-VMNetworkAdapter 的 -MaximumBandwidth 參數把頻寬限制到 1Gb 再測(官方事實,同來源)。
📊 什麼情況真的會變快?
這是整篇最該記住的一段。SMB 壓縮的效果由兩件事相乘決定:網路是不是瓶頸,以及檔案壓不壓得動。兩者缺一,加速就不會出現。
| 情境 | 網路是瓶頸? | 檔案壓得動? | 預期結果 |
|---|---|---|---|
| 1Gbps 網路傳 VHDX/ISO | 是 | 是 | 明顯變快 |
| Wi-Fi 傳資料庫備份、log | 是 | 是 | 明顯變快 |
| 1Gbps 網路傳 MP4、JPG | 是 | 否 | 幾乎沒差 |
| 100Gbps 無壅塞傳任何檔 | 否 | — | 時間差極小 |
第一列與第二列是 SMB 壓縮的主場:官方文件建議的測試素材就是 VHDX 虛擬硬碟檔,理由是「其中大部分檔案內容都壓得動」。至於系統映像檔、資料庫備份、純文字 log,官方並未逐項點名,這是依一般壓縮原理的推論——這類檔案內部有大量重複與空白區塊,可壓縮率高,省下來的傳輸量就是省下來的時間。實際效果仍請照步驟三量過再定論。
第三列是最常見的失望來源。官方在說明如何準備測試檔時,直接把 JPG 稱為「不可壓縮的檔案」——照片、影片、已經打包過的 ZIP 與 7z,內容早就被壓過一輪,SMB 再壓一次幾乎榨不出東西,你付了 CPU 成本卻買不到時間。
第四列則是官方自己點名的反例:一條沒有壅塞的 100 Gbps 網路、兩端都是快閃儲存,開不開壓縮在實務上可能一樣快。此時瓶頸不在網路,壓縮省下的傳輸量換不成時間——但官方也補了一句:它仍然會替其他應用程式減少壅塞。如果這條線上還跑著別的服務,開著仍有意義。
⚠️ 三種情況先別開
第一,你的傳輸走 SMB Direct 與 RDMA。 官方文件寫得很明確:SMB 壓縮不支援 SMB Direct 與 RDMA;即使用戶端要求壓縮、伺服器也支援,在 SMB Direct 與 RDMA 上仍然不會嘗試壓縮(官方事實,同來源)。這通常出現在有 RDMA 網卡的伺服器環境,家用情境比較少碰到。
第二,傳輸內容以已壓縮格式為主。 影音素材庫、相片備份、大量 ZIP,這類工作量開全域壓縮只會平白增加 CPU 負擔。這種情況比較適合方法 A,需要時才單次指定。
第三,兩端 CPU 都很吃緊。 壓縮是拿 CPU 換頻寬,官方對代價的描述是「傳輸期間 CPU 使用率略為增加」。若你的檔案伺服器同時跑著其他吃 CPU 的服務,建議先用步驟三的方法量過再決定。
需要整台關掉時,用戶端可以用這個設定忽略所有壓縮要求:
Set-SmbClientConfiguration -DisableCompression $true對應的群組原則是 Lanman Workstation 底下的「Disable SMB Compression」;伺服器端在 Lanman Server 底下有同名原則(官方事實,同來源)。
🔒 順帶一提:SMB 壓縮支援 SMB 簽章與 SMB 加密,也支援 SMB over QUIC 與 SMB Multichannel(官方事實,同來源)。所以不需要、也不應該為了開壓縮去關掉簽章或加密。
🔧 進階:壓縮取樣是什麼,什麼時候該打開
這是舊文章與新系統最容易對不起來的一段,值得單獨講。
在 Windows Server 2022 與 Windows 11 的初版,SMB 壓縮預設會先「試水溫」:嘗試壓縮檔案的前 524,288,000 位元組(500 MiB),並追蹤這段範圍內是否至少有 104,857,600 位元組(100 MiB)被壓縮成功。若不足 100 MiB,就放棄壓縮整個檔案的其餘部分;若達標,才繼續壓下去(官方事實,來源:Microsoft Learn《SMB Compression》與《Set-SmbClientConfiguration》)。
自 Windows Server 2022 的 KB5016693(OS Build 20348.946)與 Windows 11 的 KB5016691(OS Build 22000.918)起,這個取樣行為預設關閉,SMB 改為「只要用戶端或伺服器要求,就一律嘗試壓縮整個檔案」(官方事實,同來源)。同一批更新也讓「一律要求壓縮」與「一律拒絕壓縮」可以用群組原則或 PowerShell 設定——在此之前,多數行為只能靠登錄設定調整,而且伺服器端無法設成「不管共享設定一律要求壓縮」。官方並註明:這些 SMB 變更立即生效,不需重新開機。
所以如果你在網路上看到「SMB 壓縮只會壓前面 500MB」的說法,那是初版行為,已經不是現在的預設值。
想把取樣行為找回來(例如你的檔案前段可壓、後段是已壓縮內容,想省 CPU),用戶端可以這樣開:
Set-SmbClientConfiguration -EnableCompressibilitySampling $true取樣的兩個門檻也可以自訂:-CompressibilitySamplingSize 指定要在檔案中取樣多少位元組來尋找可壓縮資料,-CompressibleThreshold 指定要找到多少位元組的可壓縮資料才算通過(官方事實,來源:Microsoft Learn《Set-SmbClientConfiguration》)。兩者不指定時,就套用上面那組 500 MiB / 100 MiB 的預設值。
🔙 萬一改壞了:怎麼還原
動手前先記下原值,是這類全域設定的基本功。
情境一:只想取消某一項
逐項改回 $false 即可,設定同樣立即生效:
Set-SmbClientConfiguration -RequestCompression $false
Set-SmbClientConfiguration -DisableCompression $false共享端則把 -CompressData 改回 $false;對應磁碟機用 Remove-SmbMapping 移除後重新掛載即可。
情境二:設定改得太亂,想整組回預設
SmbShare 模組提供 Reset-SmbClientConfiguration,加上 -All 開關才會把所有 SMB 用戶端設定參數一次重設回預設值:
Reset-SmbClientConfiguration -All也可以只指定要還原的個別參數。請務必明確指定 -All 或個別參數——未指定任何開關時的行為,官方文件未載明,不建議盲試。動手前建議先把 Get-SmbClientConfiguration 的輸出留一份存檔,以便比對。
停止條件(符合任一,請先停手)
- 這台是公司或學校管控的設備,而你沒有 IT 授權
- 你正在用群組原則改動,卻不確定該原則會套用到哪些機器
- 指令輸出與本文預期不符(例如找不到參數,代表更新版本不足)
💡 總結:站長的判斷順序
站長我自己的判斷順序很簡單,分三步:先問這條線是不是瓶頸,再問檔案壓不壓得動,最後才問要開多大範圍。三個問題有一個答案是否定的,就別急著全域打開。
從官方文件的行文也看得出微軟的定位:SMB 壓縮的設計目標是替頻寬吃緊的環境省時間、替壅塞的網路減負擔,不是拿來刷傳輸速度紀錄的功能。1 Gbps 乙太網路與 Wi-Fi 被官方點名為最有效的場景,而 100 Gbps 無壅塞環境則被官方自己列為「可能沒差」的反例——這種把適用邊界寫清楚的官方文件並不多見,值得照著用。
實務上的建議做法:先用方法 A 的 robocopy /COMPRESS 對你真正要搬的那類檔案量一次,拿工作管理員的網路使用率與複製時間當證據,確認有效之後,再決定要不要升級到共享層或用戶端全域。跳過量測直接全域打開,最常見的結果不是變快,而是 CPU 多做工、時間沒省到。
❓ 常見問題
Q:Windows 10 可以用 SMB 壓縮嗎?
不行。微軟官方文件列出的適用版本是 Windows Server 2025、Windows Server 2022 與 Windows 11,不含 Windows 10。若你的環境還有 Windows 10 的機器,那條連線就不會走 SMB 壓縮。
Q:開了壓縮之後,傳輸還會加密嗎?
如果你原本就啟用了 SMB 加密,開壓縮不會讓它失效——官方文件明列 SMB 壓縮支援 SMB 簽章與 SMB 加密,兩者可以並存,不需要為了壓縮而關閉任何一項安全機制。但要講清楚:壓縮本身不會替你加密,加不加密取決於共享、伺服器與用戶端各自的設定。
Q:壓縮是在磁碟上壓,還是只在網路上壓?
只在網路傳輸過程中壓縮。它取代的是「先用壓縮軟體打包 → 複製 → 到對面解開」這一整套流程,檔案落地後仍是原本的格式與大小,不會變成壓縮檔。
Q:為什麼我開了卻感覺不到變快?
最常見的三個原因:傳的是已經壓過的檔案(影片、照片、ZIP)、網路本來就不是瓶頸(例如高速網路配快閃儲存),或者傳輸走的是 SMB Direct 與 RDMA——官方明列這條路徑不支援壓縮。
🔗 延伸閱讀
- Windows 認證管理員完整教學:刪除錯誤密碼,解決 NAS、共用資料夾一直登入失敗
- Windows 連 Mac 電腦共用資料夾、共用硬碟,同網域就可快速同步傳輸檔案
- Win10/Win11 辦公室共用資料夾、共用硬碟教學,含不同權限密碼設定(區域網路)
- 電腦卡卡慢?Windows 工作管理員終極指南:揪出資源怪獸與效能瓶頸
📎 參考資料來源
📖 第一級|廠商官方:
- SMB Compression – Microsoft Learn — 2026-08-02 查證
- Set-SmbClientConfiguration (SmbShare) – Microsoft Learn — 2026-08-02 查證
- SMB features in Windows and Windows Server – Microsoft Learn — 2026-08-02 查證
⚠️ 本文核心事實以第一級為準。
📅 本文查證戳記:2026-08-02 依據 Microsoft Learn 官方文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。