NAS on KnightLi的博客

Syncthing 多設備多資料夾怎麼管理？拓撲、命名和版本控制

Sun, 31 May 2026 12:23:55 +0800

Syncthing 系列目錄

Syncthing 設備一多，資料夾一多，如果不提前規劃，很快就會變亂。典型情況是：手機、平板、筆電、桌機、NAS 都在同步；資料夾裡又有照片、工作文件、程式碼專案、微信備份、電子書。每一台設備都可能修改，每一個目錄都可能共享，最後你很難判斷「這個檔案到底從哪裡來，又會同步到哪裡去」。

要把 Syncthing 用穩，核心不是多裝幾個客戶端，而是建立一套管理規則：

拓撲上使用星型結構。
資料夾上統一 ID 和路徑。
設備關係上使用引入者。
資料方向上區分備份和雙向同步。
中心節點上開啟版本控制。
暫存檔案用忽略規則過濾。

拓撲：放棄全連接，優先星型

Syncthing 是 P2P 對等架構，但不代表所有設備都要兩兩配對。

如果 5 台設備互相全連接，需要維護 10 組設備關係。新增一個資料夾時，還要在多台設備上接收、設定路徑、確認共享。設備越多，管理成本越高。

更推薦的方式是星型拓撲。

選一台長期在線、空間大、網路穩定的設備作為中心節點：

NAS
群暉
軟路由
迷你主機
24 小時開機的電腦

其他設備只和中心節點配對：

手機 ----\
平板 -----\
筆電 ---- NAS
桌機 ---/

手機不直接加入筆電，筆電也不直接加入桌機。手機要把照片同步給電腦，先同步到 NAS，再由 NAS 同步給電腦。

這樣做的好處是：

新設備只需要和 NAS 配對。
資料夾關係集中在 NAS 上管理。
NAS 可以統一做版本保留。
設備離線時，NAS 仍然能作為緩衝點。

缺點是 NAS 變得更重要了。它應該穩定運作，並且需要單獨備份。

Folder ID 比資料夾標籤更重要

在 Syncthing 中，真正識別一個同步資料夾的是 Folder ID，不是你看到的標籤名稱。

標籤只是顯示名稱，可以在不同設備上不一樣。Folder ID 才是判斷「這些設備上的資料夾是否屬於同一個同步組」的關鍵。

所以，在第一台設備建立資料夾時，建議手動指定規範 ID。

例如：

notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

不要使用隨手產生的隨機 ID，也不要只寫 test、sync、new-folder 這類無法長期維護的名字。

命名規則可以簡單一些：

雙向同步：notes-main、work-docs
手機備份：backup-pixel-photos、backup-iphone-photos
資料分發：media-ebooks、media-music
程式碼目錄：code-projects

以後在其他設備接收共享時，只要看到 Folder ID，就能判斷它是什麼用途。

中心節點路徑要規範

在 NAS 或中心電腦上，建議建立一個統一的 Syncthing 根目錄。

例如：

/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

不要把同步目錄散落在系統各處。散落的目錄短期方便，長期一定難維護。

推薦原則：

所有 Syncthing 管理的目錄放在統一根目錄下。
手機備份、工作文件、媒體資料分區存放。
資料夾名稱體現用途，不體現臨時設備狀態。
不把系統目錄、下載快取目錄直接作為長期同步目錄。

如果 Syncthing 跑在 Docker 中，還要注意容器內路徑和宿主機路徑的對應關係。

例如宿主機目錄：

`1`	`/volume1/Syncthing/Phone_Backup/iPhone15_DCIM`

映射到容器內：

`1`	`/var/syncthing/Phone_Backup/iPhone15_DCIM`

Web UI 裡填寫的是容器內路徑，不是宿主機路徑。

引入者：減少多設備配對成本

Syncthing 的 Introducer，中文介面通常稱為「引入者」。

它適合星型拓撲。

做法是：把 NAS 設為引入者。之後新設備只要和 NAS 配對，NAS 就可以把已知設備和共享關係介紹給新設備，減少你在各個設備之間重複掃碼、重複新增的工作。

適合：

家裡有多台電腦和手機。
NAS 是長期中心節點。
經常新增設備。
希望減少設備配對操作。

但不要亂用。

建議：

只把 NAS 或主伺服器設為引入者。
普通手機、平板、臨時電腦不要設為引入者。
新設備加入後，檢查它被自動新增了哪些設備和資料夾。
不信任的設備不要進入引入者管理範圍。

引入者能提高效率，也會擴大自動關聯範圍。它適合有清晰中心節點的網路，不適合混亂的臨時設備環境。

區分備份和雙向同步

多資料夾管理裡，最重要的一件事是：不要所有目錄都用 Send & Receive。

不同目錄的資料方向不一樣。

手機照片備份

手機端：

`1`	`Send Only`

NAS 端：

`1`	`Receive Only`

這樣手機負責發送照片，NAS 負責接收保存。手機清理空間、NAS 整理目錄時，都不容易互相影響。

多端文件和筆記

電腦端：

`1`	`Send & Receive`

NAS 端：

`1`	`Send & Receive`

手機端是否加入雙向同步，要看你是否真的在手機上編輯這些檔案。如果手機只查看資料，可以考慮 Receive Only。

資料分發

NAS 端：

`1`	`Send Only`

其他設備：

`1`	`Receive Only`

適合電子書、安裝包、參考資料這類中心分發目錄。

備份目錄

主設備：

`1`	`Send Only`

備份機：

`1`	`Receive Only`

再配合備份機端版本控制或快照。

NAS 上開啟檔案版本控制

多設備同步最怕誤刪和誤覆蓋。

例如：

某台電腦誤刪了工作文件。
手機清理工具刪了相簿目錄。
兩台設備同時改了同一份筆記。
某個同步規則寫錯，把空目錄同步過去。

因此，中心節點最好開啟檔案版本控制。

在 NAS 的 Syncthing Web UI 中：

打開對應資料夾設定。
進入檔案版本控制。
選擇合適的版本策略。

常用選擇是 Staggered File Versioning，也就是階段版本控制。它會按時間間隔保留歷史版本，越舊保留得越稀疏。

也可以用更簡單的策略：

Trash Can File Versioning：類似回收站。
Simple File Versioning：保留固定數量版本。
Staggered File Versioning：按時間階段保留。

如果不知道選什麼，普通家庭 NAS 可以先從 Trash Can 或 Staggered 開始。

版本控制不是完整備份，但它是多設備同步裡的後悔藥。

用忽略規則過濾暫存檔案

多設備同步程式碼專案、文件目錄或聊天備份時，暫存檔案和快取很容易製造麻煩。

常見問題：

佔用大量頻寬。
產生無意義衝突。
不同系統產生不同快取檔案。
刪除目錄時被忽略檔案阻擋。

可以在資料夾設定的 Ignore Patterns 中新增規則。

通用暫存檔案：

1
2
3

(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java 專案：

(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

如果程式碼專案本身已經用 Git 管理，通常不建議用 Syncthing 同步 .git 目錄。可以忽略：

`1`	`(?d).git/`

(?d) 的意思是：如果整個目錄準備被刪除，Syncthing 可以刪除這些本地產生的忽略檔案，不會因為殘留快取而阻止目錄刪除。

忽略規則不要一次寫太複雜。先覆蓋最明顯的快取和暫存檔案，再根據實際衝突慢慢調整。

多資料夾命名範例

可以建立一套固定命名方式。

手機照片：

1
2
3

Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone 照片：

1
2
3

Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

主筆記庫：

1
2
3

Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

工作文件：

1
2
3

Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

電子書：

1
2
3

Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

只要 ID、標籤、路徑都有規律，多設備之後也不會失控。

總結

Syncthing 的自由度很高，但自由度越高，越需要規則。

多設備、多資料夾場景下，不建議做全連接網狀同步。更穩的方式是讓 NAS 或常開電腦做中心節點，統一 Folder ID、統一路徑、統一版本控制，再用資料夾類型區分備份、雙向同步和資料分發。

這樣既保留了 Syncthing 的 P2P 能力，又把日常管理收束到一台中心設備上。設備再多，資料夾再多，也不會變成一團亂線。

Syncthing 如何同步 iPhone 照片到電腦或 NAS

Sun, 31 May 2026 12:21:54 +0800

Syncthing 系列目錄

在 iPhone 上使用 Syncthing 同步照片，和 Android 很不一樣。

原因很簡單：iOS 系統更封閉，Syncthing 官方沒有提供正式 iOS 客戶端。想在 iPhone 上使用 Syncthing 協議，通常需要第三方相容客戶端。

常見選擇有兩個：

Mobius Sync：比較主流，體驗接近原生 App，部分能力可能需要付費解鎖，具體以 App Store 當前說明為準。
FSync：免費開源的 Syncthing iOS 客戶端。

如果目標是把 iPhone 相簿同步到電腦或 NAS，Mobius Sync 是更常見的選擇。下面以它為例整理配置流程。

先理解 iOS 上的限制

在 Android 上，Syncthing-Fork 可以透過背景服務、執行條件、電池白名單等方式長期執行。但 iOS 不允許第三方同步工具無限制背景常駐。

這意味著：

不能期待它像 NAS 一樣 24 小時同步。
App 進入背景後，同步時間可能很短。
大量照片最好主動打開 App 讓它同步完。
iCloud 最佳化儲存可能影響原圖讀取。

所以，iPhone 端更適合「定期打開 App 同步照片」，而不是完全無感的背景即時同步。

第一步：安裝客戶端並授予權限

在 App Store 安裝 Mobius Sync 後，第一次打開時要重點處理幾個權限。

通知權限

建議允許通知。它可以提示同步狀態、連線狀態或錯誤資訊。

本機網路權限

這個權限非常重要。

iOS 會單獨詢問 App 是否允許存取本機網路。如果不允許，iPhone 可能無法在區域網路內發現你的電腦、NAS 或 Syncthing 節點。

如果之前誤點了拒絕，可以到系統設定中重新開啟。

相簿存取權限

如果要同步照片，必須允許存取相簿。

建議選擇：

`1`	`Full Access to Photos`

如果只給有限照片存取權限，Mobius Sync 可能只能看到你選擇的那部分照片，後續新增照片也可能不同步。

第二步：iPhone 和電腦/NAS 配對

Syncthing 的配對邏輯仍然是互相加入裝置 ID。

在 iPhone 上：

打開 Mobius Sync。
進入 Settings。
打開 Device ID。
保持 QR code 畫面。

在電腦或 NAS 上：

打開 Syncthing Web UI。
點擊 新增遠端裝置。
掃描 iPhone 上的 QR code，或手動輸入裝置 ID。
給裝置起名，例如 My-iPhone。
儲存。

回到 iPhone，等待連線請求提示，然後點擊 Accept。

到這裡，iPhone 和電腦/NAS 已經互相信任，但還沒有共享相簿。

第三步：在 iPhone 上建立相簿同步資料夾

iOS 不像 Android 那樣直接讓你選擇 /DCIM/Camera 路徑。Mobius Sync 對系統相簿做了專門支援，配置時要選擇相簿類型。

在 Mobius Sync 中：

切換到 Folders。
點擊右上角 +。
新建資料夾。

關鍵欄位：

Folder Type：選擇 Camera Roll。
Folder Label：填寫容易識別的名字，例如 iPhone_Photos。
Folder ID：可以保留自動產生，也可以用穩定英文 ID。
Folder Path：保持預設，讓客戶端關聯 iOS 系統相簿。

然後在 Sharing 區域勾選剛剛配對的電腦或 NAS。

第四步：iPhone 端設為 Send Only

相簿同步通常是「手機發給 NAS」，不是雙向編輯。

因此，在 iPhone 端把資料夾類型設為：

`1`	`Send Only`

這樣 iPhone 負責把照片傳送出去，不接收電腦或 NAS 的反向修改。

這個設定可以降低誤操作風險。比如你在電腦端整理備份目錄時，不希望這些改動影響 iPhone 相簿。

但仍然要記住：Syncthing 是同步工具，不是完整備份系統。真正的長期照片安全，還需要 NAS 端快照、檔案版本或獨立備份。

第五步：在電腦或 NAS 端接收照片

iPhone 端儲存後，電腦或 NAS 的 Syncthing Web UI 會出現提示：

`1`	`Device My-iPhone wants to share folder iPhone_Photos`

點擊新增。

設定儲存路徑。

Windows 可以類似：

`1`	`D:\Backups\iPhone_Photos`

Linux 或 NAS 可以類似：

`1`	`/volume1/photos/iphone`

如果 Syncthing 跑在 Docker 中，要填寫容器內路徑。例如宿主機掛載：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI 中應填寫：

`1`	`/var/syncthing/photos/iphone`

接收端建議設為 Receive Only

在電腦或 NAS 端，也建議把這個資料夾類型設為：

`1`	`Receive Only`

這樣接收端只接收 iPhone 傳來的照片，不把本地變化同步回 iPhone。

這是第二層保險：

iPhone 端：Send Only
NAS 端：Receive Only

兩邊都按單向備份思路配置，更符合照片歸檔場景。

iOS 背景同步的現實限制

iOS 對背景執行限制很嚴格。即使配置正確，也不要期待 Mobius Sync 一直在背景默默跑。

常見情況是：

App 打開時同步速度正常。
切到背景後還能同步一小段時間。
過一會兒系統會暫停或限制它。
位置變化、系統排程或短暫背景視窗可能再次喚醒。

最可靠的實踐很樸素：

拍了大量照片後，主動打開 Mobius Sync。
讓手機保持亮螢幕或不要太快鎖定。
等待它把新照片同步完。
再關閉 App 或鎖定螢幕。

如果你習慣每隔幾天做一次相簿備份，這個方式比較可靠。

避免 iCloud 最佳化儲存影響同步

如果 iPhone 開啟了：

`1`	`最佳化 iPhone 儲存空間`

系統可能只在本地保留縮圖，原圖留在 iCloud。第三方同步客戶端讀取照片時，可能拿不到完整原圖，導致同步失敗、跳過或需要等待系統下載。

更適合同步備份的設定是：

`1`	`下載並保留原始檔`

路徑通常在：

`1`	`設定 -> Apple ID -> iCloud -> 照片`

如果手機空間不夠，必須開啟最佳化儲存，那麼同步前可能需要先在系統相簿裡打開相關照片，讓 iPhone 把原圖從 iCloud 下載回來，再啟動 Mobius Sync 同步。

大量照片首次同步建議

第一次同步 iPhone 相簿時，可能有幾千張甚至幾萬張照片。建議不要急著一次做完。

可以這樣處理：

先同步少量照片測試。
確認 NAS 路徑正確。
確認資料夾類型是 Send Only / Receive Only。
確認接收端不會反向影響 iPhone。
再開始完整同步。

首次同步時最好：

iPhone 接入電源。
保持 Wi-Fi 穩定。
打開 Mobius Sync 前景執行。
NAS 或電腦保持在線。

照片數量很大時，同步時間可能比較長，這是正常的。

總結

iPhone 可以透過 Mobius Sync 或 FSync 接入 Syncthing 生態，把照片同步到電腦或 NAS。

但 iOS 的關鍵差異是背景限制和相簿權限。配置時要允許本機網路和完整相簿存取，資料夾類型按單向備份設計：iPhone Send Only，NAS Receive Only。如果開啟了 iCloud 最佳化儲存，還要注意本地是否真的有原圖。

用它做照片歸檔時，最穩的方式是定期主動打開客戶端同步，再讓 NAS 負責版本保留、快照和長期備份。

Android 上怎麼用 Syncthing？Syncthing-Fork 設定與照片備份

Sun, 31 May 2026 12:17:19 +0800

Syncthing 系列目錄

Android 上使用 Syncthing，常見選擇有兩個：

Syncthing 官方原版 Android 客戶端。
Syncthing-Fork 社群增強版。

如果只是簡單體驗，兩者都能用。但如果你希望長期同步手機照片、筆記或文件，更推薦 Syncthing-Fork。它對 Android 的背景、電池和網路條件適配更細，支援僅 Wi-Fi 同步、指定 Wi-Fi 同步、僅充電時執行等功能，更適合手機端長期使用。

這篇把 Android 端常規設定和照片備份合在一起講。照片備份是 Syncthing 在手機上的經典用法，但它不應該按普通雙向同步來配置。

為什麼更推薦 Syncthing-Fork

Android 系統會主動限制背景應用。手機熄屏後，系統可能暫停網路、凍結程序，甚至直接殺掉背景服務。普通同步工具如果沒有處理好這些限制，就容易出現「打開 App 才同步，鎖屏後就斷」的情況。

Syncthing-Fork 的優勢主要在手機使用體驗：

可以設定執行條件。
可以只在 Wi-Fi 下同步。
可以只在指定 Wi-Fi 下同步。
可以只在充電時同步。
對 Android 背景限制的適配更實用。

這不代表官方原版不能用，而是 Syncthing-Fork 更像「為手機長期同步場景調過的版本」。

安裝來源

Syncthing-Fork 常見安裝來源包括：

Google Play
F-Droid
GitHub Releases

優先選擇你平時信任的管道。安裝完成後，先不要急著新增裝置，先把權限和背景執行條件處理好。

第一步：授予必要權限

首次打開 Syncthing-Fork 時，重點看兩個權限。

儲存權限

Android 端同步檔案，必須讓應用能讀寫目標目錄。

較新的 Android 版本通常會提示「所有檔案存取權限」或類似權限。如果不給權限，Syncthing-Fork 可能只能看到很有限的目錄，無法讀取相簿、文件或你指定的同步資料夾。

建議：

給 Syncthing-Fork 授予必要的檔案存取權限。
同步目錄盡量放在內建儲存中的普通目錄。
不要優先選擇系統保護目錄。

例如可以使用：

1
2
3

/storage/emulated/0/SyncData
/storage/emulated/0/SyncData/Notes
/storage/emulated/0/SyncData/Photos

如果要同步相機照片，常見路徑是：

`1`	`/storage/emulated/0/DCIM/Camera`

電池最佳化白名單

這是 Android 端最關鍵的一步。

如果 Syncthing-Fork 沒有被排除出電池最佳化，手機鎖屏後系統可能殺掉同步程序。表現就是：你以為它在背景同步，實際上只有打開 App 時才動一下。

建議在系統設定中把 Syncthing-Fork 加入電池最佳化白名單。不同品牌手機名稱不一樣，可能叫：

不最佳化
允許背景執行
允許自啟動
鎖定背景
背景高耗電允許

國產 Android 系統通常還會額外限制背景和自啟動。如果同步不穩定，要同時檢查系統電池管理和應用自啟動設定。

第二步：和 NAS 或電腦配對

Syncthing 的裝置配對邏輯是互相加入 device ID。

假設手機是裝置 A，NAS 或電腦是裝置 B。

在手機端：

打開 Syncthing-Fork。
進入選單。
選擇顯示裝置 ID。
你會看到 QR code 和一長串裝置 ID。

在 NAS 或電腦端：

打開 Syncthing Web UI。
點擊 新增遠端裝置。
掃描手機 QR code，或者手動輸入手機裝置 ID。
給手機起一個清楚的名字，例如 Android-Phone 或 Pixel-Phone。
儲存。

回到手機端，通常會看到連線請求提示。點擊接受。

到這裡，兩台裝置只是建立了信任關係，還沒有同步任何資料夾。

第三步：接收 NAS 或電腦共享的資料夾

如果電腦或 NAS 已經把某個資料夾共享給手機，手機端會收到提示。

例如：

`1`	`裝置 NAS 想共享資料夾 Notes`

點擊新增後，在手機上指定本地路徑。例如：

`1`	`/storage/emulated/0/SyncData/Notes`

儲存後，手機會開始從 NAS 或電腦下載檔案。

這個路徑建議提前手動建好，避免 Syncthing-Fork 自動建立到你不熟悉的位置。

如果你同步的是 Markdown 筆記，要注意是否需要同步應用設定目錄。以 Obsidian 為例，.obsidian 目錄裡有工作區狀態、外掛設定和快取。多端外掛差異很大時，建議先只同步正文和附件。

第四步：把手機照片備份到電腦或 NAS

手機端最常見的需求是把相簿備份到 NAS 或電腦。

照片備份和普通檔案同步不一樣。大多數人想要的是「手機拍照後自動傳到 NAS」，而不是「手機刪了照片，NAS 上也跟著刪」。所以這類場景更接近單向備份，需要特別注意資料夾類型。

推薦組合是：

手機端：Send Only
電腦或 NAS 端：Receive Only

這樣手機負責傳送照片，NAS 負責接收和保存。再配合 NAS 端檔案版本或快照，誤刪風險會小很多。

手機端新增相簿資料夾

在 Syncthing-Fork 的資料夾頁面中：

點擊右上角 +。
新建資料夾。
資料夾標籤填寫容易識別的名字，例如 Pixel_Photos 或 Huawei_DCIM。
資料夾路徑選擇手機相簿目錄。
共享裝置勾選你的電腦或 NAS。

Android 相機照片通常在：

`1`	`/storage/emulated/0/DCIM/Camera`

如果你還想同步截圖、微信圖片或其他 App 保存的圖片，通常需要單獨新增資料夾。例如：

1
2

/storage/emulated/0/Pictures/Screenshots
/storage/emulated/0/Pictures/WeiXin

不同手機和應用路徑可能不同，建議先用系統檔案管理器確認。

手機端改為 Send Only

在手機端資料夾設定中，找到資料夾類型，把預設的：

`1`	`Send & Receive`

改成：

`1`	`Send Only`

這樣手機只負責把照片發出去。

這個設定的意義是：手機是照片來源。你在手機上拍了新照片，Syncthing 會把它傳給 NAS；但 NAS 端的變化不會反向寫回手機。

不過要注意，Syncthing 仍然是同步工具，不是完整備份系統。要想更穩，還需要在 NAS 端開啟檔案版本、快照或單獨備份。

接收端設定保存路徑

手機端儲存後，電腦或 NAS 的 Syncthing Web UI 會彈出提示：

`1`	`裝置 Pixel-Phone 想共享資料夾 Pixel_Photos`

點擊新增。

在接收端設定本地保存路徑。

Windows 可以類似：

`1`	`D:\Backups\Phone_Photos`

Linux 或 NAS 可以類似：

`1`	`/volume1/photos/phone`

Docker 部署時，要填寫容器內路徑。例如宿主機映射：

`1`	`- /volume1/photos:/var/syncthing/photos`

那麼 Web UI 裡應填寫：

`1`	`/var/syncthing/photos/phone`

接收端改為 Receive Only

在電腦或 NAS 端的資料夾進階設定裡，把資料夾類型設為：

`1`	`Receive Only`

這樣接收端只接收手機發來的照片，不把本地變化發回手機。

這是一層保護：即使你在電腦或 NAS 上整理照片、移動檔案、誤刪檔案，也不會直接反向影響手機裡的原圖。

更穩的做法是：NAS 端再開啟檔案版本或快照。因為 Receive Only 可以避免反向影響手機，但不能替代 NAS 自己的歷史版本能力。

第一次同步前先小規模測試

不要一開始就同步幾萬張照片。

建議先這樣測試：

在手機相簿裡臨時放 3-5 張照片。
確認電腦或 NAS 能接收到。
在手機上新增一張照片，看是否自動同步。
在手機上刪除一張測試照片，觀察 NAS 端行為。
確認結果符合預期後，再放開完整相簿。

不同資料夾類型和刪除動作的組合很容易產生誤解，先用小樣本驗證能避免大規模整理成本。

執行條件：防止偷跑流量

Syncthing-Fork 的執行條件很適合 Android。

建議進入設定裡的執行條件，至少開啟：

`1`	`僅在 Wi-Fi 連接時執行`

這樣可以避免在 5G 或 4G 網路下自動同步大檔案。

如果你只想在家裡同步，可以進一步設定指定 Wi-Fi SSID。例如只允許在家裡的 Wi-Fi 下執行，不在公司、飯店或朋友家 Wi-Fi 下同步。

充電時同步：更省電的工作流

如果你不需要即時同步，可以開啟：

僅在充電時執行

這個設定對照片備份特別實用。

一個穩定工作流是：

白天正常拍照、寫筆記。
Syncthing-Fork 不持續背景執行，減少耗電。
晚上回家連接家庭 Wi-Fi。
插上充電器。
Syncthing-Fork 自動執行，把當天照片和檔案同步到 NAS。

這比全天候背景同步更省電，也更符合手機使用習慣。

如果你同步的是隨時要用的筆記，可以不要開啟「僅充電時執行」，而是只限制 Wi-Fi。具體取決於你對即時性的要求。

Android 11 之後的儲存限制

Android 11 之後，系統對儲存存取限制更嚴格。某些目錄可能無法穩定讀寫，尤其是：

1
2

Android/data
Android/obb

SD 卡目錄也可能受限制，具體取決於手機廠商、Android 版本和檔案選擇器授權方式。

建議：

盡量在內建儲存根目錄下建立專用同步目錄。
不要把系統應用私有目錄作為主要同步目錄。
需要同步相簿時，優先選擇 DCIM/Camera 這類普通媒體目錄。
同步筆記時，建議放在 /storage/emulated/0/SyncData/Notes 這類清晰路徑。

穩定比「路徑看起來很原生」更重要。

不建議一開始同步整個：

`1`	`/storage/emulated/0`

這個目錄太大、太雜，裡面有快取、下載、應用資料和臨時檔案，容易帶來效能、權限和衝突問題。

手機端資料夾類型怎麼選

不同場景可以這樣選。

筆記雙向同步

如果手機和電腦都會編輯同一批 Markdown 筆記：

`1`	`Send & Receive`

但要注意衝突。不要在多台裝置上同時編輯同一個檔案。

手機照片備份到 NAS

如果手機主要負責傳送照片：

`1`	`Send Only`

NAS 端可以配合版本保留或快照。

手機只看資料

如果手機只需要拿到 NAS 上的資料，不希望手機誤刪影響其他裝置：

`1`	`Receive Only`

例如把資料庫、電子書、腳本參考檔同步到手機閱讀。

刪除策略要想清楚

很多人會問：手機刪照片後，NAS 上會不會刪？

這取決於資料夾類型和同步狀態。為了減少誤刪風險，建議：

手機端使用 Send Only。
NAS 端使用 Receive Only。
NAS 端開啟檔案版本。
NAS 再做快照或獨立備份。

如果你的真實目標是「歸檔」，還可以讓 Syncthing 先同步到 NAS 的中轉目錄，再由 NAS 定時任務把檔案複製到歸檔目錄。歸檔目錄不再由 Syncthing 管理。

例如：

1
2

/volume1/photos/inbox-phone
/volume1/photos/archive

Syncthing 只寫入 inbox-phone，定時腳本再把照片整理到 archive。

常見問題

鎖屏後不同步

優先檢查：

是否加入電池最佳化白名單。
是否允許背景執行。
是否允許自啟動。
是否啟用了僅充電或僅 Wi-Fi 條件。

很多時候不是 Syncthing-Fork 配錯了，而是系統背景管理把它限制住了。

找不到相簿目錄

先用系統檔案管理器確認實際路徑。常見路徑是：

`1`	`/storage/emulated/0/DCIM/Camera`

如果使用第三方相機或修圖 App，檔案可能在其他目錄。

同步很慢

檢查：

手機和 NAS 是否在同一個 Wi-Fi。
是否走了 Relay。
NAS 端 22000/TCP 和 22000/UDP 是否可用。
手機是否處於省電模式。
是否有大量小檔案。

大量小檔案同步本來就比少量大檔案慢。第一次同步完成後，後續增量通常會輕很多。

刪除手機照片後 NAS 也刪了

這說明你的同步關係把刪除動作也同步過去了。Syncthing 是同步工具，不是天然只增不刪的備份工具。

解決思路：

檢查手機端和 NAS 端資料夾類型。
NAS 端開啟檔案版本。
NAS 再配合快照或獨立備份。
如果目標是歸檔，考慮把手機照片同步到一個中轉目錄，再由 NAS 定時搬運到歸檔目錄。

總結

Android 上使用 Syncthing，關鍵不是安裝 App，而是處理好權限、背景、電池和網路條件。

Syncthing-Fork 更適合長期手機同步。它可以把同步限制在 Wi-Fi、指定 Wi-Fi 或充電狀態下，既減少耗電，也避免行動流量偷跑。

如果你的目標是手機照片備份到 NAS，建議按單向備份思路設定：手機 Send Only，電腦或 NAS Receive Only，再配合 NAS 端檔案版本、快照和獨立備份。同步負責傳輸，真正的長期安全要靠備份策略兜底。

Syncthing 多設備怎麼配置？對等網路、星型拓撲和引入者

Sun, 31 May 2026 12:13:57 +0800

Syncthing 系列目錄

Syncthing 採用的是去中心化 P2P 架構。它沒有傳統意義上的 Server 和 Client，每台設備在協議層面都是對等節點。

但在實際使用時，你可以把它配置成兩種形態：

純對等網路：每台設備都和其他設備直接配對。
星型網路：指定一台 NAS、伺服器或常開電腦作為中心節點，其他設備只和它配對。

兩種方式都符合 Syncthing 的設計，只是管理成本和使用習慣不同。

先理解「對等」和「偽伺服器」

Syncthing 裡的每台設備都有自己的 device ID。只要兩台設備互相加入對方 ID，並且共享同一個資料夾，它們就能同步。

所以，Syncthing 本身沒有「伺服器端必須保存所有資料」這個概念。你看到的「伺服器」，往往只是人為指定的一台常開設備。

例如：

NAS 長期開機、空間大，適合作為中心節點。
手機和筆電經常離線，適合作為邊緣設備。
桌機效能強，但不一定 24 小時開機，可以作為普通同步節點。

這個「中心節點」不是協議上的伺服器，而是你在拓撲設計中讓它承擔管理和中轉角色。

模式一：純對等 Mesh 網路

純對等模式下，每台設備都和其他所有設備配對。

例如你有四台設備：

NAS
桌機
筆電
手機

那麼每台設備都要和另外三台設備建立連線。這樣任何兩台在線設備之間都可以直接同步。

優點：

傳輸路徑更直接。
某台設備離線時，其他在線設備仍然可以互相同步。
不依賴某一個中心節點。

缺點：

設備越多，配對關係越複雜。
新增設備時，需要在多台舊設備上確認和配置。
資料夾共享關係容易分散。

設備數量少時，純對等模式很舒服。比如只有一台電腦和一支手機，或者兩台電腦互相同步筆記，就不需要想太複雜。

但當設備數量變成五六台以上，手動維護全連線關係會越來越麻煩。

模式二：以 NAS 為中心的星型拓撲

星型模式更適合家庭和個人生產力場景。

做法是：選一台長期開機、空間足夠、網路穩定的設備作為中心節點，例如：

NAS
群暉
軟路由
迷你主機
家用 Linux 伺服器

然後其他設備只和它配對：

1
2
3

手機 ----\
筆電 ---- NAS
桌機 ----/

手機不需要直接配對筆電，筆電也不需要直接配對桌機。它們都透過 NAS 間接同步資料。

優點：

管理簡單。
新增設備只需要和 NAS 配對。
NAS 可以承擔版本保留和備份緩衝。
適合 24 小時在線同步。

缺點：

NAS 離線時，其他設備之間不一定能繼續同步。
如果所有流量都經過 NAS，NAS 的網路和磁碟效能會影響體驗。
中心節點權限要管理好。

如果你已經有 NAS 或常開小主機，優先推薦星型拓撲。它保留了 Syncthing 的 P2P 能力，又讓日常管理更接近「中心化同步」。

多設備配置的基本順序

不管用哪種拓撲，Syncthing 的配置順序都是：

先配對設備。
再共享資料夾。
最後在接收端確認路徑。

不要反過來一開始就到處建立資料夾。先把設備關係理清楚，後面才不容易亂。

第一步：設備互聯

假設要連接設備 A 和設備 B。

設備 A 可以是手機，設備 B 可以是 NAS 或電腦。

在設備 A 上：

打開 Syncthing Web UI。
點擊右上角 操作。
選擇 顯示 ID。
複製設備 ID，或者顯示 QR code。

在設備 B 上：

打開 Syncthing Web UI。
點擊 新增遠端設備。
填入設備 A 的 ID。
給設備起一個容易識別的名稱，例如 My-Phone。
儲存。

然後回到設備 A。它通常會彈出提示：設備 B 想要連接。點擊接受。

到這一步，兩台設備已經建立了對等關係，但還沒有開始同步任何資料夾。

第二步：建立並共享資料夾

在設備 A 上點擊 新增資料夾。

常用欄位：

資料夾標籤：給自己看的名字，例如 Notes。
資料夾 ID：跨設備識別用，建議用穩定英文，例如 notes。
資料夾路徑：這台設備上的真實路徑。

然後切換到 共享 分頁，勾選剛剛配對成功的設備 B。

儲存後，設備 A 會把這個資料夾共享邀請發給設備 B。

第三步：接收共享

打開設備 B 的 Web UI，等待幾秒鐘，通常會看到提示：

`1`	`設備 A 想共享一個資料夾`

點擊新增，然後在設備 B 上指定本地儲存路徑。

例如：

`1`	`/volume1/notes`

或者 Docker 部署場景下的容器內路徑：

`1`	`/var/syncthing/notes`

儲存後，同步正式開始。

這裡要注意：不同設備上的路徑可以不一樣。Syncthing 透過資料夾 ID 識別同步關係，不要求每台設備使用相同的本地路徑。

星型拓撲怎麼配置

如果你採用 NAS 中心模式，建議這樣做：

先在 NAS 上部署 Syncthing。
所有手機、電腦、伺服器都只和 NAS 配對。
在 NAS 上建立或接收主要同步資料夾。
每台新設備只加入 NAS 的 device ID。
需要同步哪個資料夾，就在 NAS 和對應設備之間共享。

例如：

NAS
├── notes       -> 桌機、筆電、手機
├── photos      -> 手機、備份碟
├── downloads   -> 桌機、NAS
└── scripts     -> 桌機、筆電

這樣結構非常清楚。你可以把 NAS 當作同步關係的控制面板。

引入者是什麼？

Syncthing 有一個很實用的功能：Introducer，中文介面裡通常叫「引入者」。

它適合多設備場景。

假設你把 NAS 設為引入者。之後新設備只要和 NAS 配對，NAS 就可以把它知道的其他設備介紹給新設備，也可以幫助同步已有的共享關係。

這樣可以減少重複點擊和重複配對。

適合：

家裡有多台電腦和手機。
NAS 作為長期中心節點。
經常新增設備。
希望減少手動維護設備關係。

但也要注意，引入者會擴大自動建立關係的範圍。不要把不完全信任的設備設為引入者，也不要在不清楚拓撲的情況下隨手勾選。

更穩妥的做法是：

只把 NAS 或主伺服器設為引入者。
普通手機、筆電不要設為引入者。
新設備加入後，檢查它被自動加入了哪些設備和資料夾。

資料夾類型決定資料方向

Syncthing 的權限控制主要體現在資料夾類型上。

進入資料夾設定，在選項裡可以調整 Folder Type。

常見三種：

Send & Receive

預設模式。雙方都可以發送和接收變更。

適合：

多設備共同編輯筆記。
多台電腦同步文件。
普通雙向同步目錄。

這是最接近「真正對等」的模式。

Send Only

本機只發送，不接收其他設備的變更。

適合：

資料源頭。
主目錄向其他設備分發。
不希望遠端修改影響本機。

例如你把 NAS 上的某個軟體安裝包目錄設為 Send Only，讓其他電腦只接收。

Receive Only

本機只接收，不把本地改動發送出去。

適合：

備份機。
唯讀鏡像。
防止本地誤刪反向影響主目錄。

例如 NAS 用來接收手機照片，手機端刪除照片時，你不希望 NAS 也跟著刪，就要認真設計資料夾類型和刪除策略。

不同目錄可以用不同拓撲

Syncthing 的拓撲不一定要全站統一。你可以按資料夾設計。

例如：

notes：桌機、筆電、手機、NAS 都使用 Send & Receive。
photos：手機發送，NAS 接收並保留版本。
downloads：NAS 和桌機同步，手機不參與。
backup：主電腦 Send Only，NAS Receive Only。

不要把所有目錄都套進同一種規則。多設備同步真正重要的是資料方向，而不是設備數量。

衝突和誤刪要提前想

多設備同步最常見的問題不是配置失敗，而是同步成功之後發生誤刪或衝突。

容易出問題的場景：

兩台設備同時編輯同一個檔案。
手機端應用自動清理目錄。
一台設備路徑填錯，建立了空目錄並同步過去。
把快取、暫存檔、工作區狀態檔案一起同步。
NAS 端沒有開啟版本保留。

建議：

重要目錄在 NAS 上開啟檔案版本。
使用 .stignore 排除快取和暫存檔。
新資料夾第一次同步前，先用少量測試檔案驗證。
不確定刪除策略時，不要把所有設備都設為 Send & Receive。

總結

Syncthing 是 P2P 對等架構，但不代表你必須把所有設備配成複雜網狀結構。

小規模設備可以用純對等模式；設備多、有 NAS 或常開主機時，更建議使用星型拓撲。讓 NAS 承擔中心節點和引入者角色，其他設備只跟 NAS 建立關係，管理會簡單很多。

真正要想清楚的是：哪些設備可信、哪些目錄要同步、資料從哪裡來、誤刪時誰負責保留版本。拓撲只是手段，資料流向才是配置的核心。

用 Docker 部署 Syncthing：Compose、連接埠和目錄映射避坑

Sun, 31 May 2026 12:12:05 +0800

Syncthing 系列目錄

在 Docker 中部署 Syncthing，很適合 NAS、家用伺服器和 VPS 場景。它可以作為 24 小時在線的同步節點，長期承擔照片、文件、Markdown 筆記或下載目錄的同步任務。

Docker 部署 Syncthing 的重點不是「能不能跑起來」，而是三個問題：

設定目錄要持久化。
需要同步的資料目錄要映射到宿主機。
連接埠和權限要提前處理好。

如果這三點沒有處理好，容器更新後可能遺失設定，Web UI 裡填寫路徑時可能找不到真實目錄，或者同步時出現 Permission denied。

目錄規劃

建議先在伺服器或 NAS 上準備一個獨立目錄，例如：

1
2

mkdir -p ~/syncthing
cd ~/syncthing

這個目錄裡放 docker-compose.yml，並用子目錄保存 Syncthing 設定：

1
2
3

syncthing/
├── docker-compose.yml
└── config/

同步資料目錄可以放在 NAS 或宿主機已有路徑中，例如：

1
2

/volume1/downloads
/volume1/photos

設定目錄和資料目錄要分開。config 保存 Syncthing 自己的設定、密鑰和索引資料庫；downloads、photos 這類目錄才是你要同步的真實資料。

方案一：Docker Compose

更推薦使用 Docker Compose，後續更新、重啟和遷移都更清楚。

在 ~/syncthing/docker-compose.yml 寫入：

version: "3"

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    hostname: my-nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./config:/var/syncthing/config
      - /volume1/downloads:/var/syncthing/downloads
      - /volume1/photos:/var/syncthing/photos
    ports:
      - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

啟動：

`1`	`docker compose up -d`

查看狀態：

1
2

docker compose ps
docker logs -f syncthing

打開 Web UI：

`1`	`http://伺服器IP:8384`

首次進入後台後，先設定 GUI 使用者名稱和密碼。

方案二：docker run

如果只是快速測試，也可以直接使用 docker run：

docker run -d \
  --name syncthing \
  --hostname my-nas-syncthing \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v /path/to/config:/var/syncthing/config \
  -v /path/to/data1:/var/syncthing/data1 \
  --restart unless-stopped \
  syncthing/syncthing:latest

這裡的 /path/to/config 和 /path/to/data1 必須換成宿主機真實路徑。

例如：

1
2

-v /volume1/docker/syncthing/config:/var/syncthing/config
-v /volume1/photos:/var/syncthing/photos

長期使用時，還是建議改成 Compose 檔案，避免每次重建容器都要重新拼命令。

容器內路徑和宿主機路徑

Docker 新手最容易混淆的是路徑。

比如 Compose 裡寫了：

1
2

volumes:
  - /volume1/photos:/var/syncthing/photos

左邊 /volume1/photos 是宿主機路徑。右邊 /var/syncthing/photos 是容器內路徑。

進入 Syncthing Web UI 新增同步資料夾時，資料夾路徑必須填寫容器內路徑：

`1`	`/var/syncthing/photos`

這樣 Syncthing 實際操作的才是宿主機上的：

`1`	`/volume1/photos`

如果你在 Web UI 裡填 /volume1/photos，容器內部通常沒有這個路徑，Syncthing 可能會報錯，或者在容器檔案系統裡建立一個你並不想要的新目錄。

設定目錄必須持久化

下面這一行很關鍵：

`1`	`- ./config:/var/syncthing/config`

Syncthing 的設定檔、裝置密鑰和索引資料庫都會放在設定目錄裡。如果不把它掛載到宿主機，容器刪除或重建後，裝置 ID 可能變化，原來的裝置配對關係也會失效。

建議把設定目錄放在穩定路徑中，例如：

`1`	`/volume1/docker/syncthing/config`

不要把設定目錄放進臨時目錄，也不要和同步資料目錄混在一起。

連接埠和防火牆

常用連接埠如下：

8384/TCP   Web UI 管理後台
22000/TCP 裝置間同步流量
22000/UDP QUIC 同步流量
21027/UDP 區域網路發現

如果 Syncthing 部署在家用 NAS 上，通常要檢查：

NAS 自帶防火牆是否放行這些連接埠。
Docker 網橋連接埠是否正確映射。
路由器是否隔離了 Wi-Fi 和有線網路。
手機和電腦是否在同一網段。

如果部署在雲伺服器上，還要檢查雲廠商安全群組。尤其是 22000/TCP 和 22000/UDP，如果沒有放行，其他裝置可能只能透過 relay 連接，速度會明顯變慢。

8384 是管理後台連接埠，不建議直接暴露到公網。如果確實要遠端管理，至少要設定強密碼，最好再配合反向代理、HTTPS、存取控制或 VPN。

權限問題：PUID 和 PGID

如果啟動後 Syncthing 能打開 Web UI，但同步目錄時出現：

`1`	`Permission denied`

通常是容器程序沒有宿主機目錄的讀寫權限。

先在宿主機上查看目前使用者的 UID 和 GID：

id

輸出類似：

`1`	`uid=1000(user) gid=1000(user) groups=1000(user)`

然後把 Compose 裡的環境變數改成對應值：

1
2
3

environment:
  - PUID=1000
  - PGID=1000

同時確認宿主機目錄本身允許這個使用者讀寫：

`1`	`ls -ld /volume1/photos`

必要時調整目錄擁有者或權限：

`1`	`sudo chown -R 1000:1000 /volume1/photos`

在 NAS 系統上不要盲目遞迴修改整個共享目錄權限，尤其是多人共享目錄。更穩妥的做法是給 Syncthing 單獨準備一個同步目錄，或者在 NAS 權限管理介面給對應使用者授權。

Web UI 首次安全設定

容器啟動後，訪問：

`1`	`http://伺服器IP:8384`

首次進入後台，Syncthing 通常會提示設定 GUI 使用者名稱和密碼。這一步不要跳過。

建議：

立即設定 GUI 使用者名稱和強密碼。
不把 8384 暴露到公網。
遠端訪問時優先走 VPN、SSH 隧道或受控反向代理。
如果使用反向代理，確認只代理 Web UI，不要誤開放其他不必要連接埠。

如果管理後台被別人控制，對方就可能新增裝置、修改共享目錄、改變同步關係。Syncthing 的同步資料傳輸是加密的，但管理入口本身仍然需要保護。

在 Web UI 中新增同步目錄

以照片目錄為例，Compose 中已經掛載：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI 裡新增資料夾時：

Folder Label：可以寫 Photos。
Folder ID：建議使用穩定英文 ID，例如 photos。
Folder Path：填寫 /var/syncthing/photos。
Sharing：選擇要共享給哪些裝置。
Folder Type：按需求選擇 Send & Receive、Send Only 或 Receive Only。

如果這台 Docker 節點是 NAS 中心節點，常見配置是：

普通文件：Send & Receive
手機照片彙整：NAS 上設為 Receive Only
對外分發目錄：NAS 上設為 Send Only

具體選擇要看你的資料流向。不要所有目錄都無腦雙向同步。

更新容器

使用 Compose 時，更新通常是：

1
2

docker compose pull
docker compose up -d

只要設定目錄和資料目錄都正確掛載，更新容器不會遺失裝置 ID、配對關係和同步目錄設定。

更新前可以先備份設定目錄：

`1`	`tar -czf syncthing-config-backup.tar.gz ./config`

設定目錄裡包含裝置私鑰，不要把備份檔案隨便上傳到公共位置。

常見問題

Web UI 打不開

先檢查容器是否運行：

1
2

docker ps
docker logs syncthing

再檢查連接埠映射：

`1`	`docker port syncthing`

如果容器正常，仍然打不開，檢查宿主機防火牆、NAS 防火牆或雲伺服器安全群組。

新增目錄後提示不存在

檢查你在 Web UI 裡填寫的是不是容器內路徑。

例如宿主機路徑是：

`1`	`/volume1/downloads`

容器內路徑是：

`1`	`/var/syncthing/downloads`

Web UI 裡應該填後者。

只能透過 Relay，速度很慢

優先檢查：

22000/TCP 是否放行。
22000/UDP 是否放行。
路由器連接埠轉發是否正確。
雲伺服器安全群組是否同時放行 TCP 和 UDP。
本機防火牆是否攔截 Docker 映射連接埠。

Relay 能提高可連接性，但不適合長期承擔大量同步流量。

同步後檔案權限不對

先確認容器運行使用者是否正確，再確認宿主機目錄權限。Linux、NAS、Windows 共享目錄之間的權限模型不同，不要把 Syncthing 當成權限修復工具。

對於跨系統同步，盡量同步普通檔案和目錄，少同步依賴複雜 ACL、擁有者、擴展屬性的系統目錄。

一個更穩的使用方式

如果你的目標是把 NAS 或伺服器作為中心節點，可以這樣設計：

NAS 上用 Docker 跑 Syncthing。
設定目錄掛載到 /volume1/docker/syncthing/config。
每類資料單獨掛載，例如 /volume1/photos、/volume1/notes。
手機、電腦分別新增 NAS 的裝置 ID。
重要目錄在 NAS 端開啟檔案版本。
Web UI 只在內網或 VPN 內訪問。
NAS 本身再做獨立備份，不把同步當作唯一備份。

這樣 Syncthing 負責裝置間同步，NAS 負責長期在線和版本緩衝，真正的備份再交給快照、外接硬碟或異地備份。

總結

Docker 部署 Syncthing 的關鍵，是把「容器生命週期」和「同步資料生命週期」分開。

容器可以隨時更新、重建、遷移；但設定目錄和資料目錄必須穩定保存在宿主機上。Web UI 裡填寫的是容器內路徑，宿主機權限要透過 PUID、PGID 和目錄授權處理，連接埠要按實際網路環境放行。

只要這幾件事配置清楚，Syncthing 很適合作為 NAS、伺服器和個人裝置之間的輕量同步層。

Syncthing 怎麼用？從裝置配對到檔案同步的實用筆記

Sun, 31 May 2026 11:59:09 +0800

Syncthing 系列目錄

Syncthing 適合用來做多裝置之間的點對點檔案同步。它不是傳統網路硬碟，也不是把所有資料先上傳到某個中心伺服器再下載回來，而是讓已授權的裝置直接交換檔案。

如果你正在考慮用它同步 Markdown 筆記、照片備份、設定檔或家庭 NAS 目錄，重點不只是「能不能同步」，而是先理解幾個基本概念：裝置、資料夾、裝置 ID、同步方向、發現方式和衝突處理。

Syncthing 解決什麼問題

Syncthing 的核心場景是：你有兩台或多台裝置，希望它們之間保持某個目錄一致。

典型例子：

Windows 桌機和筆電之間同步工作資料。
手機和 NAS 之間同步照片或文件。
多台 Linux 伺服器之間同步設定範例、腳本或小型資料目錄。
Obsidian、Joplin 外部附件、Markdown 筆記目錄在多裝置間同步。

它更適合「自己控制裝置和資料」的同步場景。如果你需要多人權限管理、線上預覽、分享連結或協作編輯，傳統網路硬碟或文件協作平台會更合適。

第一次啟動後會發生什麼

官方入門文件建議把兩台機器並行設定。Syncthing 裡，一台機器叫一個 device。你正在設定的機器是 local device，另一台要同步的機器是 remote device。

第一次啟動 Syncthing 時，它會產生設定檔、加密金鑰和裝置 ID，並預設在本機開啟 Web GUI：

`1`	`http://127.0.0.1:8384/`

這個 Web GUI 是日常設定入口。官方文件也提到，預設可能會建立一個 Default Folder，通常對應使用者目錄下的 Sync 資料夾。你可以先用它測試，也可以後面刪除並新增自己的目錄。

裝置 ID 是配對基礎

Syncthing 的裝置配對靠 device ID。

每台裝置首次啟動時都會產生自己的金鑰，裝置 ID 可以理解為這個裝置憑證的可讀指紋。兩台裝置只有互相加入對方的裝置 ID，才會建立連線並同步。

實際操作順序通常是：

在兩台裝置上都啟動 Syncthing。
分別開啟 Web GUI。
在 A 上加入 B 的 device ID。
在 B 上加入 A 的 device ID。
選擇要共享的資料夾。
儲存後等待兩邊連線。

裝置 ID 不需要像密碼一樣保密，但也不要隨便把自己的同步拓撲公開到不必要的地方。真正需要保護的是裝置私鑰、Web GUI 管理權限和同步目錄本身。

資料夾不是自動全機同步

Syncthing 同步的是你明確新增的 folder，不會預設同步整台機器。

每個資料夾都有自己的路徑、ID、共享裝置和同步類型。常見做法是按用途拆分：

notes/：Markdown 筆記。
photos-inbox/：手機照片中轉。
docs/：多裝置文件目錄。
scripts/：小腳本和設定範例。

不要一開始就同步過大的系統目錄、下載目錄或混雜目錄。目錄越複雜，衝突、忽略規則、權限差異和掃描成本越容易變成長期維護問題。

三種常見資料夾類型

官方文件裡把資料夾類型分得很清楚。實際使用時，先理解這三種就夠了。

Send & Receive

這是預設模式。這個資料夾既傳送本機變更，也接收其他裝置變更。

適合：

多台電腦共同編輯筆記。
多裝置共同維護文件。
普通雙向同步目錄。

如果兩台裝置同時改了同一個檔案，Syncthing 會產生衝突檔案，而不是直接靜默覆蓋。

Send Only

這個模式下，本機像「參考副本」。它會向其他裝置傳送變化，但不會套用其他裝置傳來的變化。

適合：

主裝置向備份裝置分發檔案。
希望某台機器上的目錄狀態作為基準。
不希望遠端修改反向影響本機。

如果遠端發生變化，本機可能顯示 out of sync。此時 Web GUI 會提供 Override Changes，用本機狀態覆蓋叢集裡的其他狀態。這個按鈕要謹慎使用。

Receive Only

這個模式和 Send Only 相反。它接收叢集裡的變更，但本地改動不會再傳給其他裝置。

適合：

備份目標。
唯讀鏡像。
不希望本地誤操作污染主同步目錄的裝置。

如果本地出現修改，Web GUI 會提示 Revert Local Changes，可以把本地變更撤回到叢集版本。

防火牆和連接埠要先看

Syncthing 能透過發現服務、NAT、relay 等機制讓裝置互相找到，但網路越清楚，連線越穩定。

官方防火牆文件列出的關鍵連接埠是：

1
2
3

22000/TCP
22000/UDP
21027/UDP

其中：

22000/TCP 用於 TCP 同步流量。
22000/UDP 用於 QUIC 同步流量。
21027/UDP 用於本地發現廣播或多播。

如果裝置在同一個區域網路內，但一直發現不了，優先檢查本機防火牆、路由器隔離、Wi-Fi 和 LAN 是否被分到不同網段。

如果裝置跨公網或跨 NAT，能做連接埠轉發時，直接連線通常比 relay 更好。沒有連接埠轉發時，relay 也可能讓裝置連上，但效能會比直連差。

Linux 上如果使用 ufw 並安裝了對應套件，可以用：

1
2

sudo ufw allow syncthing
sudo ufw status verbose

Web GUI 預設只監聽本機的 127.0.0.1:8384。如果要遠端存取 GUI，可以改成 0.0.0.0:8384，但這代表管理介面對外暴露，必須同時考慮密碼、HTTPS、反向代理或 SSH 隧道。普通家庭場景下，更推薦用 SSH 隧道存取遠端 GUI。

`.stignore` 要放在同步根目錄

如果有些檔案不想同步，可以在同步資料夾根目錄建立 .stignore。

注意幾個細節：

.stignore 必須放在同步資料夾的根目錄。
規則相對於同步根目錄生效。
.stignore 本身不會同步到其他裝置。
檔案內容應使用 UTF-8 編碼。

一個簡單例子：

(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?d) 的作用是：當這些被忽略檔案阻止目錄刪除時，允許 Syncthing 刪除它們。適合 .DS_Store 這類系統自動產生檔案。

驚嘆號 ! 是反向規則，用來把某些檔案重新納入同步。但反向規則可能導致 Syncthing 遍歷本來會忽略的目錄。規則很多時，最好先從簡單規則開始。

檔案版本不是本地復原

Syncthing 支援檔案版本保留，但它的語義容易誤解。

官方文件強調，版本保留是「接收遠端變更時，把舊版本歸檔」。也就是說，如果 A 開啟了版本保留，B 修改了檔案並同步到 A，A 會把被替換的舊檔案保存起來。但如果 A 自己本地修改了檔案，Syncthing 不能替 A 保存修改前的版本。

常見版本策略包括：

Trash Can File Versioning：類似回收桶，被遠端刪除或替換的檔案移到 .stversions。
Simple File Versioning：保留固定數量的歷史版本。
Staggered File Versioning：按時間間隔保留版本，越舊越稀疏。
External File Versioning：交給外部腳本處理。

如果你用 Syncthing 同步重要文件，建議至少在備份目標裝置上開啟簡單版本或回收桶版本。它不能代替完整備份，但能減少誤刪和誤覆蓋的損失。

同步衝突如何產生

Syncthing 會識別衝突。兩台裝置同時修改同一個檔案，而且內容不同，就可能產生類似這樣的衝突檔案：

`1`	`filename.sync-conflict-date-time-modifiedBy.ext`

這比靜默覆蓋安全，但也代表你要定期清理衝突檔案。

容易產生衝突的場景：

多裝置同時開啟同一份 Markdown 筆記。
應用程式自動寫入同一個狀態檔。
同步 .obsidian/workspace.json 這類裝置狀態檔。
Windows、macOS、Android 之間出現大小寫檔名差異。

如果同步筆記，建議把正文、附件和模板同步；工作區狀態、快取、外掛臨時檔要謹慎處理，必要時放進 .stignore。

安全邊界

Syncthing 的安全目標之一是：未授權裝置不能加入同步叢集，傳輸中的檔案內容不能被旁路監聽者讀取。

官方安全文件說明，裝置間流量由 TLS 保護，連線建立時會檢查裝置憑證指紋是否在允許清單中。換句話說，只有雙方配置了彼此的裝置 ID，才會真正建立同步關係。

但這不等於「使用 Syncthing 這件事不可見」。例如：

開啟全域發現時，裝置會向發現伺服器公告裝置 ID 和監聽位址。
本地發現會在區域網路內發送廣播或多播。
relay 伺服器會知道連線裝置的 device ID，但不能解密同步內容。
Web GUI 如果對外開放，會暴露這台機器執行了 Syncthing。

所以安全建議很直接：

不要把 Web GUI 暴露到公網，除非你明確做好認證和加密。
只加入你信任的裝置。
重要目錄配合系統磁碟加密或單獨備份。
不需要全域發現、relay 或自動升級時，可以按場景關閉，但要接受連線便利性下降。

不受信任裝置加密

Syncthing 還支援 Untrusted / Encrypted Devices。這個功能可以讓某個不受信任裝置只保存加密後的資料。

一個典型場景是：你有一台雲端伺服器或外部機器，希望它參與同步、承擔中轉或備份角色，但不希望它看到明文檔案。可信裝置向它傳送資料時，會使用資料夾密碼加密；其他可信裝置拿到同樣密碼後，可以從這個不受信任裝置同步並解密。

但官方文件也提醒，這個功能仍應視為 beta / testing。它適合有明確需求的人謹慎使用，不建議一開始就作為主同步方案。

需要特別記住：

檔案資料、檔名、時間、雜湊和目錄結構會被保護。
資料夾 ID、標籤和大致檔案大小不屬於完整保護範圍。
密碼和 folder ID 要可靠保存。
不受信任裝置上的資料夾類型要設為 Receive Encrypted。

如果只是家庭 NAS、自己的電腦和手機之間同步，通常先用普通可信裝置模式，把系統登入、磁碟加密和備份做好，會更容易維護。

實用設定建議

如果你準備用 Syncthing 長期同步筆記或文件，可以按這個思路設定：

每類資料單獨建資料夾，不要混在一個超大目錄裡。
主力電腦使用 Send & Receive。
NAS 或備份機可以考慮 Receive Only，並開啟檔案版本。
手機端只同步必要目錄，不要同步應用快取目錄。
用 .stignore 排除快取、臨時檔、工作區狀態檔。
區域網路內優先保證 22000/TCP、22000/UDP、21027/UDP 可用。
Web GUI 盡量保持本機監聽，需要遠端管理時優先用 SSH 隧道。
重要資料不要只依賴同步，仍然需要獨立備份。

適合和不適合

Syncthing 適合：

你希望資料主要留在自己的裝置上。
你願意理解裝置配對、同步目錄和衝突處理。
你有 NAS、家用伺服器或多台個人裝置。
你想同步 Markdown、照片中轉、腳本、輕量文件。

Syncthing 不太適合：

需要多人線上協作編輯。
需要網頁端檔案預覽和分享連結。
需要細粒度團隊權限。
不想處理任何網路、防火牆和衝突問題。

它更像一個可靠的「裝置間同步層」，而不是完整的雲端硬碟產品。用得好，Syncthing 可以把 NAS、電腦、手機連成一個可控的資料網路；用得太隨意，也可能因為衝突、誤刪、忽略規則和網路設定變成維護負擔。

參考資料

用 NAS 自建 Git Server 同步本地 Markdown 筆記

Sat, 30 May 2026 16:14:19 +0800

如果已經有一台本地 NAS，又希望筆記盡量保存在自己手裡，可以把 Markdown 筆記放進 NAS 上的 Git Server，再用 Android 和 Windows 用戶端同步。這個方案不依賴公共雲碟，適合 Obsidian、Markor、VS Code、Typora 這類以本地 Markdown 檔案為核心的筆記工具。

它的基本思路很簡單：

NAS 上建立一個 Git 裸倉庫，作為筆記的中央倉庫。
Windows 端 clone 倉庫，用常見編輯器寫筆記。
Android 端 clone 同一個倉庫，用 Git 用戶端拉取和推送。
每次換裝置前先 pull，寫完後再 commit 和 push。

這種方式不是最傻瓜的同步方案，但可控性很好，歷史版本也清楚。只要養成提交習慣，就能把筆記、設定、圖片附件都放在自己的 NAS 上長期保存。

方案適合誰

這套方案適合下面幾類人：

家裡或辦公室已經有 NAS。
筆記主要是 Markdown 檔案。
希望筆記資料保存在本地網路裡，而不是只放在商業雲碟上。
需要 Windows 和 Android 多裝置同步。
能接受 Git 的基本操作，例如 clone、pull、commit、push。

如果你希望完全自動、完全無感同步，Syncthing、WebDAV 或筆記軟體自帶同步可能更省心。Git 更適合重視版本歷史、可回滾、可遷移和可控性的筆記庫。

一、在 NAS 上安裝 Git Server

不同 NAS 系統的入口不一樣，但目標都一樣：讓 NAS 提供一個可以透過 SSH 存取的 Git 倉庫。

常見做法有三種：

方式	適合場景
NAS 套件中心安裝 Git Server	群暉、威聯通等成品 NAS，想少折騰
Docker 部署 Gitea	想要 Web 介面、帳號管理和更完整的 Git 服務
直接用 SSH + 裸倉庫	只給自己用，追求簡單穩定

如果只是個人筆記同步，SSH + 裸倉庫已經夠用。假設 NAS 上有一個專門的 Git 使用者 git，倉庫存放目錄為 /volume1/git，可以在 NAS 終端機裡執行：

1
2
3

mkdir -p /volume1/git/notes.git
cd /volume1/git/notes.git
git init --bare

裸倉庫不直接編輯檔案，只作為同步中心。實際寫筆記的目錄在 Windows 或 Android 本地。

接著確認 SSH 可以存取 NAS：

`1`	`ssh git@192.168.1.10`

如果 NAS 支援 SSH 公鑰登入，建議設定公鑰，避免每次推送都輸入密碼。Windows 和 Android 可以分別產生自己的 SSH key，再把公鑰加入 NAS 的 authorized_keys 或 Git Server 使用者設定裡。

二、Windows 端設定

Windows 端建議安裝 Git for Windows，然後選擇一個本地目錄存放筆記，例如 D:\Notes。

首次 clone：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

進入目錄後，可以建立基本結構：

1
2

cd D:\Notes
mkdir inbox, daily, projects, resources

然後用 Obsidian、VS Code、Typora 或其他 Markdown 編輯器打開 D:\Notes。寫完第一批筆記後提交：

1
2
3

git add .
git commit -m "初始化笔记库"
git push origin main

如果倉庫預設分支是 master，就把命令裡的 main 換成 master。也可以統一改成 main：

1
2

git branch -M main
git push -u origin main

日常使用時，Windows 端可以保持這個節奏：

git pull --rebase
git add .
git commit -m "更新笔记"
git push

三、Android 端設定

Android 端可以使用支援 Git 的用戶端來同步本地 Markdown 目錄。常見選擇包括：

工具	用法
Termux	最靈活，接近 Linux 命令列
MGit	圖形介面 Git 用戶端，適合不想敲太多命令
GitJournal	更像筆記應用，適合簡單 Markdown 筆記

如果選擇 Termux，可以先安裝 Git 和 OpenSSH：

1
2

pkg update
pkg install git openssh

產生 SSH key：

`1`	`ssh-keygen -t ed25519 -C "android-notes"`

把產生的公鑰加入 NAS 的 Git 使用者授權裡。然後在手機本地選擇一個目錄 clone 倉庫：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git ~/notes`

如果想讓普通 Android 編輯器存取這個目錄，可以把倉庫放到共享儲存目錄，例如：

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

之後可以用 Markor、Obsidian Android 或其他 Markdown 編輯器打開 /sdcard/Notes。手機端修改後，再回到 Termux 執行：

cd /sdcard/Notes
git pull --rebase
git add .
git commit -m "手机更新笔记"
git push

Android 上最容易出問題的是權限和路徑。Termux 自己的家目錄更穩定，但部分編輯器不一定能直接存取；/sdcard 方便編輯器存取，但權限、檔案監聽和效能可能受系統限制。可以先用少量筆記測試，再決定最終目錄。

四、Obsidian 和 Joplin 怎麼落地

NAS Git Server 只解決「檔案放在哪裡、怎麼同步」的問題。真正寫筆記時，還需要選擇筆記應用。這裡可以分成 Obsidian 方案和 Joplin 方案。

方案	同步方式	適合人群	注意點
Obsidian + Git	筆記目錄就是 Git 倉庫，Windows 和 Android 都拉取同一個倉庫	想要雙鏈、知識圖譜、外掛生態和純 Markdown 檔案的人	Android 上最好先測試 Git 用戶端和 Obsidian 對同一目錄的存取權限
Joplin + Git	不建議直接把 Joplin 資料庫放進 Git；更適合用 Joplin 自帶同步，或定期匯出 Markdown 到 Git	想要網頁剪藏、端到端加密、傳統筆記本結構的人	Joplin 的本地資料不是普通 Markdown 資料夾，不適合直接當 Git 筆記庫同步

Obsidian 方案

Obsidian 最適合這套 NAS Git 同步方案。原因是它的 vault 本質上就是一個普通資料夾，裡面是 Markdown 檔案、圖片附件和設定檔。你可以直接把 D:\Notes 或 /sdcard/Notes 作為 Obsidian vault。

Windows 端流程：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

然後在 Obsidian 裡打開 D:\Notes。

Android 端流程：

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

然後在 Obsidian Android 裡打開 /sdcard/Notes。

Obsidian 方案建議：

單人使用時，可以提交 .obsidian/，讓主題、外掛和部分設定在多裝置間同步。
如果 Android 和 Windows 外掛差異很大，可以只提交筆記正文，不提交 .obsidian/workspace.json 這類裝置狀態檔。
圖片附件建議統一放到 attachments/，避免散落在各級目錄裡。
每次打開 Obsidian 前先 git pull --rebase，寫完後再 commit 和 push。

可以準備一個 .gitignore，減少裝置狀態檔造成的衝突：

1
2
3

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Joplin 方案

Joplin 的思路和 Obsidian 不一樣。它雖然使用 Markdown 語法，但本地資料主要由應用資料庫管理，不是一個可以直接拿來 Git 同步的普通 Markdown 資料夾。因此，不建議把 Joplin 的設定目錄或資料庫目錄直接放進 Git 倉庫。

如果你更喜歡 Joplin，有兩種更穩的做法：

做法	說明
使用 Joplin 自帶同步	透過 WebDAV、Nextcloud、Joplin Cloud、Dropbox、OneDrive 等方式同步，NAS 可以提供 WebDAV 或 Nextcloud
定期匯出 Markdown 到 Git	Joplin 作為主力筆記應用，定期把筆記匯出為 Markdown，再提交到 NAS Git 倉庫做備份

如果 NAS 上已經有 WebDAV 或 Nextcloud，Joplin 直接連 NAS 同步會比 Git 更順滑。它還可以啟用端到端加密，適合不想處理 Git 衝突、但又希望資料盡量在自己控制範圍內的人。

Joplin + NAS 的推薦路線是：

NAS 上開啟 WebDAV 或部署 Nextcloud。
Joplin Windows 端設定同一個同步目標。
Joplin Android 端設定同一個同步目標。
需要版本備份時，再定期匯出 Markdown 到 Git 倉庫。

簡單判斷：

想要「本地 Markdown 資料夾 + 雙鏈 + Git 歷史」，選 Obsidian。
想要「傳統筆記應用 + 網頁剪藏 + 加密同步」，選 Joplin。
想把 NAS Git Server 作為主同步中心，Obsidian 更合適。
想把 NAS 當成私有雲同步後端，Joplin 更合適。

五、推薦的筆記目錄結構

筆記庫不要一開始就設計得太複雜。可以先用下面這種結構：

Notes/
  inbox/
  daily/
  projects/
  resources/
  attachments/
  README.md

含義很直觀：

inbox/ 放臨時記錄。
daily/ 放日記、日誌和每日流水。
projects/ 放專案筆記。
resources/ 放長期資料。
attachments/ 放圖片、PDF 和其他附件。

如果使用 Obsidian，可以把這個目錄直接作為 vault。.obsidian/ 設定是否提交，要看個人習慣。單人多裝置使用時可以提交；如果不同裝置外掛差異很大，也可以只提交部分設定。

六、避免同步衝突

Git 同步筆記的關鍵不是命令多複雜，而是習慣要穩定。

建議遵守幾條規則：

換裝置寫筆記前，先執行 git pull --rebase。
寫完一輪後，及時 commit 和 push。
不要在兩台裝置上同時長時間編輯同一個檔案。
圖片和大附件不要無限塞進 Git 倉庫。
定期在 NAS 外再備份一份倉庫。

如果出現衝突，Git 會標出衝突檔案。Markdown 文字衝突通常不難處理，但手機上處理體驗比較差，所以盡量在 Windows 上解決衝突。

七、是否需要自動同步

可以給 Windows 寫一個簡單腳本，把 pull、add、commit、push 串起來。但筆記同步不建議完全無腦自動提交，因為誤刪、空提交、衝突和大附件都可能被自動推上去。

更穩妥的方式是半自動：

打開筆記前先手動拉取。
寫完後執行一個腳本提交。
每次提交訊息簡單說明這次改了什麼。

例如 Windows 可以準備一個 sync-notes.ps1：

git pull --rebase
git add .
git commit -m "更新笔记"
git push

如果沒有變更，git commit 會提示 nothing to commit，這不是問題。

八、這個方案的優缺點

方面	說明
優點	資料在本地 NAS，版本歷史清晰，可回滾，可遷移，適合 Markdown
缺點	需要理解 Git，衝突需要手動處理，移動端體驗不如雲同步順滑
適合	技術使用者、本地優先筆記、個人知識庫、專案文件
不適合	完全不想接觸命令列、需要多人即時協作、頻繁同步大附件

我的建議

如果只是想在 Android 和 Windows 之間同步普通 Markdown 筆記，可以先從最小方案開始：NAS 上一個裸倉庫，Windows 上 Git for Windows，Android 上 Termux 或 MGit。不要一開始就引入複雜權限、自動化腳本和過度分類。

等這套流程跑順以後，再考慮 Gitea、自動備份、SSH key 分裝置管理、附件分倉庫、定時任務等擴展。筆記系統最重要的是長期穩定可用，而不是第一天就把所有功能堆滿。

一句話：NAS Git Server 適合把 Markdown 筆記做成本地優先、可追溯、可遷移的個人資料庫；它不如雲同步省心，但控制權更清楚。

Above 4G Decoding 是什麼？為什麼多 PCIe 設備、NAS 擴展卡和大顯存顯卡建議開啟

Sun, 24 May 2026 00:51:13 +0800

Above 4G Decoding 是主板 BIOS 裡的一個底層 PCIe 資源分配選項。它常見於 NAS、小主機、工作站、多顯卡主機、軟路由、HBA / SATA 擴展卡和本地 AI 機器的調試過程中。

簡單說，它的作用是：允許 64 位系統把 PCIe 設備需要的 MMIO 地址空間，分配到 4GB 以上的物理地址範圍。

這句話聽起來很底層，但它解決的問題很現實：當主板上插了顯卡、NVMe、網卡、SATA 擴展卡、採集卡、HBA 等多個 PCIe 設備時，如果所有設備都擠在 4GB 以下的老地址空間裡搶位置，就可能出現資源分配失敗、設備不識別，甚至開機卡死。

為什麼會有 4GB 這個邊界

4GB 邊界來自 32 位時代的歷史包袱。

32 位地址空間最大只能尋址：

`1`	`2^32 bytes = 4GB`

現代電腦早就是 64 位 CPU 和 64 位作業系統，記憶體也經常是 16GB、32GB、64GB 甚至更多。但主板在開機自檢和 PCIe 設備初始化時，仍然需要考慮舊式相容性。很多 PCIe 設備的資源映射預設會先被安排在 4GB 以下的地址空間內。

問題在於，4GB 以下的空間並不全是給記憶體用的。系統還要在裡面劃出一部分地址給硬體設備使用。

這就是 MMIO。

MMIO 是什麼

MMIO 是 Memory-Mapped I/O，記憶體映射輸入輸出。

CPU 不能像讀寫普通記憶體那樣直接「摸到」PCIe 設備內部的暫存器和顯存。它需要把設備的一部分暫存器、緩衝區或顯存窗口映射到系統地址空間中。CPU 讀寫這段地址，就等於在和設備通信。

可以粗略理解為：

設備需要一塊地址範圍。
主板給它分配一段系統物理地址。
CPU 訪問這段地址時，實際訪問的是 PCIe 設備。

這塊映射區域不是真的普通 RAM，而是硬體設備占用的地址窗口。

在舊式預設配置下，很多設備的 MMIO 區域會被限制在 4GB 以下，常見就是 3GB 到 4GB 附近那段空間。設備少時通常沒問題，設備一多就開始擁擠。

BAR 是什麼

每個 PCIe 設備都會透過 BAR 向主板宣告自己需要多少地址空間。

BAR 是 Base Address Register，基地址暫存器。它的作用是告訴主板：

`1`	`我需要一塊 MMIO 空間，請給我分配一個地址範圍。`

顯卡、NVMe、SATA 控制器、網卡、HBA、USB 擴展卡都可能需要 BAR 空間。設備越多，占用的地址窗口越多。顯卡這類設備還可能需要更大的映射空間。

如果 4GB 以下可用 MMIO 空間不夠，主板就可能無法給後插入的設備分配資源。

不開啟它，可能出現什麼問題

如果關閉 Above 4G Decoding，主板會更傾向於把 PCIe 設備資源塞進 4GB 以下的地址空間。設備少時看不出來，設備多時就可能出現問題。

常見場景包括：

一塊獨立顯卡。
一個或多個 NVMe SSD。
一張 JMB585 / ASM1166 SATA 擴展卡。
一張 2.5G / 10G 網卡。
一個 Wi-Fi / 藍牙模組。
額外的 HBA、採集卡、USB 擴展卡。

這些設備都要向主板申請 BAR / MMIO 地址空間。如果 4GB 以下空間被占滿，主板可能會出現：

某張 PCIe 卡無法識別。
BIOS 裡看不到設備。
Linux / Windows 裡設備缺失或報資源錯誤。
開機卡在 POST 階段。
黑屏或光標閃爍。
多設備同時插入時才出問題，單獨插每張卡又正常。

在 JMB585 SATA 擴展卡場景裡，很多人會遇到插卡後主板卡在 BIOS 前，或者加了 NVMe、網卡後擴展卡突然不識別。除了 Option ROM、CSM、PCIe Gen 速率之外，PCIe 地址空間分配也是一個值得排查的方向。

開啟 Above 4G Decoding 後發生了什麼

開啟：

`1`	`Above 4G Decoding = Enabled`

等於告訴主板：允許把支援 64 位地址的 PCIe 設備 MMIO 資源，分配到 4GB 以上的地址空間。

這樣，PCIe 設備不必全部擠在 4GB 以下的小空間裡。主板可以把部分設備的 BAR / MMIO 映射放到更高地址，減少資源衝突。

對現代 64 位系統來說，這通常是合理配置。尤其是以下機器：

多盤 NAS。
多網卡軟路由。
插了 SATA / HBA 擴展卡的小主機。
多顯卡工作站。
AI 推理或訓練機器。
同時有獨顯、NVMe、採集卡、擴展卡的桌面主機。

它的目標不是提升普通軟體性能，而是讓硬體資源分配更寬鬆。

它和 JMB585 / SATA 擴展卡有什麼關係

JMB585 這類 SATA 擴展卡本身不一定需要很大的 MMIO 空間。但問題往往不是它單獨需要多少，而是整台機器上所有 PCIe 設備一起搶地址空間。

例如一台小主機裡可能同時有：

一個 NVMe 系統盤。
一個板載網卡。
一個 Wi-Fi 模組。
一張 JMB585 五口 SATA 擴展卡。
可能還有獨立顯卡或其他控制器。

如果 BIOS 資源分配比較保守，JMB585 可能成為最後一個被初始化的設備。前面的設備已經占掉不少 4GB 以下資源，到它申請 BAR 時，主板就可能分配失敗或進入異常狀態。

這時開啟 Above 4G Decoding，可以讓主板把一部分設備資源安排到 4GB 以上，從而降低衝突機率。

它不能修復壞卡，也不能解決所有 PCIe 鏈路訓練問題，但在「多設備插滿後才異常」的場景裡非常值得嘗試。

它和 Resizable BAR / SAM 的關係

很多人是因為顯卡效能設定才第一次見到 Above 4G Decoding。例如 NVIDIA / AMD 顯卡相關的：

Resizable BAR
Re-Size BAR
ReBAR
Smart Access Memory
SAM

它們和 Above 4G Decoding 有關係，但不是同一個東西。

Above 4G Decoding 是基礎條件。它允許 PCIe 設備的 MMIO 資源被分配到 4GB 以上。

Resizable BAR 是進一步的能力。傳統情況下，CPU 訪問顯卡顯存時，通常只能通過較小窗口分段訪問，例如 256MB 級別的映射窗口。啟用 ReBAR 後，CPU 可以一次性映射更大範圍的顯存，理論上能減少訪問切換開銷。

很多主板要求先開啟 Above 4G Decoding，再開啟 Resizable BAR。所以可以理解為：

Above 4G Decoding：先允許設備地址放到 4GB 以上。
Resizable BAR / SAM：再允許顯卡 BAR 窗口變大。

對 NAS 和 SATA 擴展卡來說，重點通常不是 ReBAR，而是前者提供的 PCIe 地址空間。

開啟它有什麼副作用

對現代 64 位 Windows、Linux、Ubuntu、Debian、TrueNAS、Proxmox 等系統來說，開啟 Above 4G Decoding 通常沒有明顯負面影響。

但仍然要注意幾點：

老舊 32 位作業系統可能不適合開啟。
某些很老的 BIOS 或古董 PCIe 設備可能相容性不好。
修改 BIOS 後如果無法啟動，可以清 CMOS 或恢復預設設置。
如果啟用了 ReBAR / SAM，還要確認顯卡、主板、系統和驅動都支援。

在現代硬體和 64 位系統上，它通常是建議開啟的底層良性配置，尤其是設備較多時。

什麼時候建議開啟

以下情況建議開啟 Above 4G Decoding：

使用 64 位作業系統。
主板上插了多張 PCIe 設備。
有獨立顯卡，尤其是 4GB 以上顯存的顯卡。
使用 JMB585、ASM1166、HBA、陣列卡、採集卡等擴展設備。
組裝多盤 NAS 或軟路由。
使用多顯卡、AI 算力卡或本地大模型機器。
插上某張 PCIe 卡後開機卡死、找不到特定 PCIe 卡。
單獨插設備正常，多設備一起插就異常。

如果你正在排查 JMB585 SATA 擴展卡 POST 階段卡死，推薦把它和這些設定一起檢查：

關閉 CSM。
禁用不需要的 Storage OpROM。
將 PCIe 速率從 Auto 或 Gen3 改成 Gen2。
開啟 Above 4G Decoding。
更換 PCIe 插槽。

在 BIOS 裡一般叫什麼

不同主板廠商命名略有差異，常見名稱包括：

Above 4G Decoding
Above 4GB MMIO BIOS assignment
Memory Mapped I/O above 4GB
64-bit PCIe decoding
PCI 64-bit Resource Handling

常見位置包括：

Advanced
PCIe Settings
PCI Subsystem Settings
Chipset
North Bridge
IO Ports
Boot

有些主板會把它和 Resizable BAR 放在一起，有些則藏在高級 PCIe 或芯片組選項裡。

小結

Above 4G Decoding 的核心作用，是讓主板可以把 PCIe 設備的 MMIO / BAR 地址空間分配到 4GB 以上。它解決的不是驅動問題，而是 BIOS / PCIe 資源分配層面的地址空間問題。

對只有少量設備的普通電腦來說，它可能看起來無感。對多盤 NAS、多網卡軟路由、插了 JMB585 / ASM1166 SATA 擴展卡的小主機、多顯卡工作站、本地 AI 主機來說，它就很重要。

如果你遇到插上 PCIe 擴展卡後卡 BIOS、黑屏、光標閃爍、設備不識別，或者多設備同時插入才出問題，Above 4G Decoding = Enabled 是一個值得優先檢查的 BIOS 設置。它不是萬能藥，但它能讓現代 64 位硬體擺脫 4GB 以下地址空間的舊限制，減少 PCIe 資源衝突。

PCIe 擴展卡插上後 BIOS 前光標閃爍卡死，該怎麼排查

Sun, 24 May 2026 00:46:52 +0800

如果 PCIe 擴展卡插上後，機器連 BIOS 介面都進不去，只停在黑屏或主板啟動前的光標閃爍畫面，這通常不是 Linux 驅動問題，而是更早階段的硬體級卡死。

這個階段作業系統還沒有載入，所以 pci=nomsi、pcie_aspm=off 這類 Linux 核心參數完全幫不上忙。問題發生在 POST（加電自檢）階段，常見卡點包括 PCIe 鏈路訓練、PCIe 資源分配、Option ROM 載入、Legacy / UEFI 相容性衝突，或者擴展卡本身異常。

換句話說：如果連 BIOS 都進不去，先不要急著改 Linux。要先讓主板能完成自檢。

先理解這個故障意味著什麼

正常開機時，主板會掃描 PCIe 設備，給設備分配 bus、I/O、MMIO 等資源，並決定是否載入設備自帶的 Option ROM。某些 SATA 擴展卡、HBA、網卡、採集卡或轉接卡會帶有用於啟動支援或設備初始化的韌體，主板韌體可能會嘗試讀取它。

如果擴展卡、主板 BIOS、PCIe 插槽、電源、外接設備或 Option ROM 其中某一環不相容，就可能卡在主板自檢階段。典型表現是：

黑屏，只剩光標閃爍。
卡在主板 Logo 前後。
按 Del、F2、F11、F12 無法進入 BIOS 或啟動選單。
拔掉這張 PCIe 擴展卡後一切正常。
換回原來的 NVMe、顯卡、網卡後都能啟動。

這種情況可以理解為「主板還沒來得及把控制權交給系統，就已經被這張卡卡住了」。

哪些 PCIe 擴展卡容易觸發這個問題

這類 POST 卡死不只會出現在 JMB585 SATA 擴展卡上。凡是需要主板在開機階段初始化、分配資源或載入 Option ROM 的 PCIe 設備，都可能觸發類似問題。

比較常見的設備包括：

JMB585、ASM1166 等 PCIe SATA 擴展卡。
LSI / Broadcom HBA 或陣列卡。
2.5G、10G、萬兆電口或光口網卡。
PCIe 轉 M.2 / U.2 / SATA 轉接卡。
視訊採集卡。
USB 3.x 擴展卡。
帶 Option ROM 的老顯卡、老 RAID 卡或伺服器拆機卡。
做工一般、韌體魔改、EEPROM 異常的廉價 PCIe 卡。

這些設備的問題不一定是「壞了」，也可能只是和目前主板 BIOS、插槽通道、PCIe 速率、啟動模式或地址資源分配不相容。

為什麼還沒進系統，Linux 核心參數無效

pci=nomsi、pcie_aspm=off、libata.force 這類參數都屬於 Linux 核心啟動參數。它們必須等核心載入後才會生效。

而 BIOS 前光標閃爍、主板 Logo 前卡死、按鍵進不了 BIOS，說明系統還停在 POST 階段。此時運行的是主板韌體，不是 Linux 核心。換句話說，Linux 還沒開始執行，自然也沒有機會讀取這些參數。

所以這類故障的排查重點不是先改 /etc/default/grub，而是先處理：

BIOS / UEFI 啟動模式。
CSM / Legacy 相容層。
PCIe Option ROM。
PCIe 鏈路訓練。
PCIe 地址空間和資源分配。
擴展卡、插槽、供電和外接設備。

第一步：拔掉擴展卡上的外接設備

先做最低風險的排查：只保留 PCIe 擴展卡插在主板上，把接在擴展卡上的 SATA 資料線、外接設備線纜或硬碟供電先斷開，讓這張卡處於「不掛設備」的狀態。

然後開機測試：

如果拔掉硬碟或設備後能進 BIOS，說明擴展卡本身大概率沒有把主板卡死，問題可能在某塊硬碟、線材、供電或啟動盤識別上。
如果仍然卡死，說明問題更可能在擴展卡和主板 PCIe / BIOS 相容性上。

為什麼硬碟也可能導致 POST 卡死？有幾種常見原因：

某塊硬碟的引導扇區或分區表異常，主板 BIOS 誤判為啟動盤後讀取卡死。
多塊機械碟同時上電，電源瞬時電流不足，導致 SATA 控制器或硬碟異常。
某根 SATA 線接觸不良，導致控制器初始化階段等待超時。
某塊硬碟本身健康狀態很差，拖慢整條初始化流程。

如果拔盤後能啟動，可以再一塊一塊接回硬碟，找到具體是哪塊盤或哪根線觸發問題。

第二步：拔卡進 BIOS，關閉 CSM

很多 PCIe 擴展卡卡在 POST 階段，和 CSM / Legacy 啟動相容層有關。

CSM 是 Compatibility Support Module，用來讓 UEFI 主板相容舊式 Legacy 啟動。問題在於，一些廉價 SATA 擴展卡或魔改卡可能帶有老舊 Option ROM。主板在 CSM 模式下會嘗試載入這些舊式啟動韌體，結果和現代 UEFI 韌體發生衝突。

CSM 和 Option ROM 為什麼會卡住 POST

POST 階段主板會枚舉 PCIe 設備，並判斷這些設備是否帶有可啟動韌體。很多老式存儲卡、RAID 卡、HBA、網卡和 SATA 擴展卡會提供 Option ROM，用來讓主板在作業系統啟動前識別設備，甚至支援從這張卡啟動。

問題是，Option ROM 往往很依賴 BIOS 實作。有些擴展卡的 Option ROM 老舊、魔改、損壞，或者只在特定伺服器主板上測試過。現代消費級主板在 CSM / Legacy 模式下嘗試載入它時，就可能出現初始化死循環、黑屏、光標閃爍或鍵盤無響應。

關閉 CSM、禁用 Storage OpROM 的目的，就是讓主板不要在啟動前嘗試執行這張卡自己的啟動韌體。只要系統盤不接在這張擴展卡上，多數 NAS 和資料盤場景並不需要從擴展卡啟動，交給 Linux / Windows 進入系統後再識別通常更穩。

操作步驟：

關機斷電，拔掉這張 PCIe 擴展卡。
使用主板原有顯卡、核顯或已有啟動盤開機，進入 BIOS。
找到 CSM、Compatibility Support Module 或 Legacy Boot 相關選項。
將 CSM 設置為 Disabled。
啟動模式盡量改成 UEFI Only。
保存 BIOS 設置並關機。
重新插上 PCIe 擴展卡測試。

如果關閉 CSM 後能正常過 POST，說明之前大概率是 Legacy Option ROM 或啟動相容層衝突。

第三步：禁用 PCIe / Storage Option ROM

有些 BIOS 會提供更細的 Option ROM 控制項，例如：

PCIe Option ROM
Storage OpROM
Mass Storage Controller Option ROM
Launch Storage OpROM Policy
Option ROM Messages

如果能找到類似選項，可以把擴展卡所在插槽或存儲控制器相關 Option ROM 設置為：

`1`	`Disabled`

或：

`1`	`Do Not Launch`

這樣做的意思是：不要嘗試從這張擴展卡載入啟動韌體，只把它當成普通 PCIe 設備交給作業系統識別。

如果你的系統盤不接在這張擴展卡上，而只是用它掛資料盤、NAS 盤、倉庫盤、網卡或採集設備，那麼通常不需要從這張卡啟動。禁用它的 Option ROM 反而更穩。

第四步：強制 PCIe 速率為 Gen2 或 Gen1

很多卡標稱走 PCIe Gen3，但主板、轉接卡、線材、槽位和擴展卡做工不夠好時，PCIe 鏈路訓練可能在 Gen3 階段談不攏，主板就會卡在等待設備完成初始化的階段。

PCIe Gen3 鏈路訓練失敗是什麼表現

PCIe 設備插上後，主板和設備會協商鏈路寬度和速率，例如 x1、x2、x4，以及 Gen1、Gen2、Gen3。這個過程叫 Link Training。

如果設備、插槽、轉接卡、主板走線或供電不穩定，雙方可能在較高速率上無法完成協商。常見表現是：

插卡後卡在 BIOS 前黑屏或光標閃爍。
主板 Logo 停很久，按鍵無響應。
偶爾能啟動，偶爾完全卡死。
強制 PCIe Gen2 後恢復正常。
換到另一個槽位後恢復正常。
同一張卡在短槽、芯片組槽上能用，在 CPU 直連大槽上不穩定，或反過來。

這不是作業系統層面的「掉盤」，而是主板和設備還沒完成 PCIe 鏈路初始化。強制 Gen2 / Gen1 的目的，是降低訊號速率，犧牲一點理論帶寬換穩定啟動。

更穩妥的做法是先讓它降速：

拔掉這張 PCIe 擴展卡。
進入 BIOS。
找到對應 PCIe 插槽的速率設置，例如 PCIe Speed、PCIe Link Speed、Max Link Speed。
把 Auto 或 Gen3 改成 Gen2。
如果 Gen2 仍不穩定，再嘗試 Gen1。
保存關機，重新插卡測試。

對 SATA 機械碟來說，Gen2 x1 或 Gen2 x2 通常已經夠用。穩定性優先時，不必執著 Gen3。

如果 BIOS 沒有提供 PCIe 速率設置，才考慮物理降速方案。有人會通過給擴展卡金手指部分引腳貼絕緣膠帶，讓卡退回 x1 模式，以此驗證是否是第二條 PCIe lane 或高頻訊號品質導致卡死。這種方法有風險，容易貼錯位置或造成接觸問題，不建議作為第一選擇。優先用 BIOS 降速。

第五步：開啟 Above 4G Decoding

如果主板上同時有 NVMe、顯卡、無線網卡、HBA、採集卡或多個 PCIe 設備，BIOS 在 POST 階段需要給它們分配地址空間和 MMIO 資源。老主板或資源分配策略比較保守的 BIOS，可能因為資源不足或地址衝突卡住。

可以嘗試開啟：

`1`	`Above 4G Decoding`

常見位置在 BIOS 的 Advanced、PCIe Settings、PCI Subsystem Settings、Chipset 或類似選單下。

它的作用是允許 PCIe 設備使用 4GB 以上的地址空間，有助於緩解多設備環境下的資源分配問題。雖然這個選項常被顯卡直通、礦卡、HBA 和多 PCIe 設備場景提到，但對某些 SATA 擴展卡卡 POST 的情況也值得嘗試。

第六步：換 PCIe 插槽

不要只在一個槽位上反覆試。不同 PCIe 插槽背後的通道來源可能不同：

靠近 CPU 的長槽通常是 CPU 直連，優先給顯卡使用。
一些短槽或第二條長槽可能來自芯片組 PCH。
某些槽會和 NVMe、SATA、Wi-Fi 或其他設備共享通道。

如果擴展卡插在 CPU 直連大槽上卡死，可以嘗試插到芯片組引出的短槽或帶寬較低的槽上。反過來也一樣，如果 PCH 槽不穩定，也可以試試其他槽位。

同時建議查看主板說明書，確認是否存在「插了某個 M.2 後某個 PCIe 槽失效」之類的共享規則。

如何判斷是卡壞了還是主板相容性問題

如果做完上面步驟仍然卡在光標閃爍，還可以做兩個交叉驗證：

把這張擴展卡插到另一台電腦上測試。
換一張確認正常的同類 PCIe 擴展卡插到目前主板上測試。

判斷邏輯可以這樣看：

同一張卡在多台電腦上一插就卡死：更像擴展卡本身有硬體或韌體問題。
這張卡只在目前主板卡死，換電腦正常：更像主板 BIOS、插槽通道、PCIe 速率或資源分配相容性問題。
目前主板換其他同類擴展卡正常：更支持原卡異常。
目前主板換其他 PCIe 設備也不穩定：要懷疑主板插槽、供電、BIOS 設置或 PCIe 通道共享問題。

如果這張卡在多台電腦上一插就卡死，而其他擴展卡在目前主板正常，基本可以懷疑：

擴展卡 EEPROM / Option ROM 資料損壞。
擴展卡存在短路或供電異常。
金手指、焊點、晶振或電源晶片有硬體問題。
卡的韌體和多個主板 BIOS 都不相容。

如果它只在某一台主板上卡死，則更可能是主板 BIOS、插槽通道、PCIe 速率、CSM 或資源分配問題。

不要把系統參數當成 BIOS 階段解法

需要特別強調：只要機器還沒進入 Linux，pci=nomsi、pcie_aspm=off、libata.force 這類核心參數都不會生效。

這些參數只能處理作業系統接管硬體之後的問題，例如 Linux 下掉盤、中斷異常、PCIe ASPM 喚醒失敗等。對於 BIOS 前光標閃爍、POST 階段卡死，它們沒有機會執行。

所以這類問題的排障重點是：

BIOS 設置。
PCIe 鏈路訓練。
Option ROM。
插槽和資源分配。
擴展卡和外接設備的物理狀態。

小結

PCIe 擴展卡插上後卡在 BIOS 前光標閃爍，本質上是 POST 階段就被卡住。最常見的突破口是：

斷開所有外接設備，排除硬碟或供電誘因。
關閉 CSM，切換到純 UEFI。
禁用 Storage / PCIe Option ROM。
將 PCIe 速率從 Auto / Gen3 降到 Gen2 或 Gen1。
開啟 Above 4G Decoding。
更換 PCIe 插槽測試。

如果這些都無效，並且這張卡在其他電腦上也會卡死，就要高度懷疑擴展卡本身硬體或韌體損壞。對 NAS 和存儲伺服器來說，穩定性比參數漂亮更重要。遇到這類 POST 級卡死，優先讓主板能穩定過自檢，再談 Linux 裡的核心參數和驅動排查。

pci=nomsi 和 pcie_aspm=off 詳解：Linux 下 SATA 擴展卡不認盤、掉盤、卡死時該怎麼排查

Sun, 24 May 2026 00:41:23 +0800

在 Linux / Ubuntu 上使用 PCIe SATA 擴展卡時，很多人會遇到不認盤、運行一段時間掉盤、系統卡死，或者開機階段卡在 PCIe 鏈路訓練的問題。常見對象包括 JMB585、ASM1166 等 SATA 擴展卡，尤其是在 NAS、小主機、工控機、魔改主板或廉價轉接卡環境裡更容易出現。

pci=nomsi 和 pcie_aspm=off 是排查這類問題時經常用到的兩個 Linux 核心參數。它們看起來都和 PCIe 有關，但解決的不是同一個問題：

pci=nomsi 主要處理 中斷訊號問題，也就是設備和 CPU 之間的「通知方式」不穩定。
pcie_aspm=off 主要處理 PCIe 電源管理問題，也就是鏈路進入省電狀態後喚醒失敗或訊號不穩。

如果把這兩個參數混在一起理解，很容易變成玄學調參。更合理的做法是先看現象，再判斷應該優先懷疑中斷、鏈路省電，還是硬體本身。

pci=nomsi：禁用消息信號中斷

pci=nomsi 可以拆開看：

PCI：外設部件互連相關設備。
no：禁用。
MSI：Message Signaled Interrupts，消息信號中斷。

它的意思是：讓 Linux 核心不要給 PCI 設備使用 MSI / MSI-X 中斷機制，而是退回傳統的 INTx 中斷方式。

MSI 是什麼

傳統硬體設備要通知 CPU「我有事要處理」，通常依賴物理中斷引腳，也就是傳統 IRQ。這個機制比較老，能用，但共享和擴展能力有限。

後來出現了 MSI / MSI-X。設備不再一定要拉物理中斷引腳，而是向特定記憶體地址寫入一條消息。CPU 收到這條消息後，就知道哪個設備觸發了中斷。對現代系統來說，MSI / MSI-X 通常更靈活，也更適合高併發設備。

問題在於，並不是每張 PCIe 擴展卡的韌體都把 MSI 做得足夠可靠。部分廉價擴展卡、二手拆機卡、橋接晶片方案，或者韌體品質一般的 SATA 控制器，在 Linux 驅動下可能出現 MSI 消息異常、中斷丟失或中斷風暴。

常見表現包括：

開機檢測 PCIe 擴展卡時卡住。
SATA 擴展卡完全不認盤。
系統隨機卡死。
dmesg 中出現類似 irq xx: nobody cared 的報錯。
某張卡在 Windows 下看似正常，但 Linux 下很不穩定。

這類問題的核心不是硬碟本身，也不是檔案系統，而是設備和 CPU 之間的中斷通信方式不可靠。

加上 pci=nomsi 後會發生什麼

啟用：

`1`	`pci=nomsi`

等於告訴 Linux 核心：不要讓 PCI 設備使用進階的 MSI 消息中斷，統一退回傳統 INTx 中斷模式。

這可能帶來一點效能和併發效率損失，尤其是在高吞吐、高手動中斷頻率設備上。但對家用 NAS、SATA 擴展卡、普通機械硬碟陣列來說，實際影響通常不明顯。它的價值在於繞過某些設備韌體或橋接晶片的 MSI 相容性問題，讓系統能穩定識別設備並處理 I/O。

簡單說，pci=nomsi 處理的是「設備通知 CPU 的方式不可靠」。

pcie_aspm=off：禁用 PCIe 活動狀態電源管理

pcie_aspm=off 也可以拆開看：

PCIe：PCI Express，高速串行擴展總線。
ASPM：Active State Power Management，活動狀態電源管理。
off：關閉。

它的意思是：關閉 PCIe 鏈路的省電機制，讓 PCIe 鏈路不要進入低功耗狀態。

ASPM 是什麼

ASPM 是 PCIe 總線上的省電機制。當系統發現某條 PCIe 鏈路暫時沒有資料傳輸時，可以把鏈路切到低功耗狀態，例如 L0s 或 L1。等設備再次有資料讀寫時，再把鏈路喚醒回正常工作狀態。

在設計良好的硬體上，這套機制可以降低功耗，而且對使用者幾乎無感。但在一些消費級主板、小主機、工控機、廉價 SATA 擴展卡、轉接板或訊號品質一般的硬體上，問題會出在「睡下去以後醒不穩」。

典型情況是：JMB585、ASM1166 這類 PCIe SATA 擴展卡在空閒後進入低功耗狀態，下一次存取硬碟時鏈路需要從 L1 喚醒。如果控制器、主板、轉接線、供電或韌體品質不夠好，喚醒可能太慢，或者鏈路恢復時發生物理層抖動。Linux 核心就可能認為設備短暫失聯。

常見 dmesg 表現包括：

1
2
3

pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
ata1: link is slow to respond, please be patient
ata1: COMRESET failed (errno=-16)

隨後可能出現：

硬碟掉線。
陣列降級。
檔案系統變成唯讀。
NAS 服務異常。
系統 I/O 卡死。
重啟後硬碟又暫時恢復正常。

這類問題最麻煩的地方在於，它不一定開機就出現，往往是運行一段時間、空閒後喚醒，或高負載切換時突然發生。

加上 pcie_aspm=off 後會發生什麼

啟用：

`1`	`pcie_aspm=off`

等於告訴核心：關閉全系統 PCIe ASPM 省電功能。PCIe 鏈路不管空閒還是忙碌，都盡量保持在正常連接狀態，不要進入低功耗睡眠。

副作用是功耗可能略有上升。對桌機、NAS、小主機來說，通常只是幾百毫瓦到一兩瓦級別；對筆記型電腦來說，可能會影響續航。它換來的好處是減少因為 PCIe 鏈路睡眠和喚醒造成的掉盤、鏈路訓練錯誤和物理層報錯。

簡單說，pcie_aspm=off 處理的是「PCIe 鏈路睡著後醒不穩」。

兩個參數的區別

可以把它們理解成兩類不同問題：

參數	解決的核心問題	常見表現	主要副作用
`pci=nomsi`	中斷訊號衝突、MSI / MSI-X 相容性差	開機卡死、完全不認盤、`irq xx: nobody cared`、系統死機	極高併發下中斷效率可能下降
`pcie_aspm=off`	PCIe 省電喚醒失敗、鏈路訊號不穩	剛開機正常，運行一會兒掉盤，`PCIe Bus Error`、`COMRESET failed`	功耗略升，筆電續航略降

所以它們不是互相替代關係。一個管中斷，一個管鏈路電源管理。

如果機器開機階段就卡死、設備完全不認，優先懷疑 pci=nomsi。如果開機正常、運行一段時間後掉盤，或者 dmesg 裡有 PCIe Physical Layer、COMRESET、link is slow to respond 之類資訊，優先懷疑 pcie_aspm=off。

是否應該兩個一起加

很多 NAS 玩家會直接同時加：

`1`	`pci=nomsi pcie_aspm=off`

這確實是快速排查的辦法，尤其是在 JMB585、ASM1166、小主機、轉接卡、供電和線材都不太確定的環境裡。它可以同時繞開 MSI 相容性問題和 ASPM 喚醒問題。

但從排障角度，更推薦先記錄現象和日誌：

如果是中斷報錯或啟動卡死，先試 pci=nomsi。
如果是運行後掉盤、PCIe Bus Error、COMRESET，先試 pcie_aspm=off。
如果問題嚴重且急著恢復穩定，可以兩個一起加，穩定後再拆開驗證。

這樣能知道到底是哪一類問題導致的，後續換卡、換槽、換主板或調整 BIOS 時更有依據。

Ubuntu / Debian 中如何永久生效

編輯 Grub 配置檔案：

`1`	`sudo nano /etc/default/grub`

找到這一行：

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"`

在雙引號內追加參數，參數之間用空格隔開。例如：

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi pcie_aspm=off"`

保存並退出。如果使用 Nano，按 Ctrl+O 保存，回車確認，再按 Ctrl+X 退出。

更新 Grub 並重啟：

1
2

sudo update-grub
sudo reboot

重啟後，可以查看目前核心啟動參數是否已經生效：

`1`	`cat /proc/cmdline`

如果輸出裡能看到 pci=nomsi 和 pcie_aspm=off，說明參數已經進入目前核心啟動命令列。

還應該檢查哪些地方

這兩個參數很有用，但它們不是所有掉盤問題的萬能解法。排查 SATA 擴展卡和 NAS 掉盤時，也建議同時檢查：

SATA 資料線是否鬆動或品質太差。
硬碟供電是否穩定，尤其是多盤同時啟動時。
PCIe 插槽是否接觸不良。
擴展卡是否過熱。
主板 BIOS 是否有 PCIe ASPM、Above 4G Decoding、PCIe speed 等相關選項。
SATA 擴展卡韌體是否有已知問題。
系統日誌中是否有硬碟本體壞道、I/O error 或 SMART 告警。

如果硬碟 SMART 已經報錯，或者供電本身不穩，單靠核心參數無法真正解決問題。

小結

pci=nomsi 和 pcie_aspm=off 都常用於 Linux 下 PCIe SATA 擴展卡不穩定的排查，但它們解決的是兩條不同鏈路：

pci=nomsi：關閉 MSI / MSI-X，繞開中斷通信相容性問題。
pcie_aspm=off：關閉 PCIe ASPM，避免鏈路省電後喚醒失敗。

對 JMB585、ASM1166、NAS、小主機和廉價 PCIe 擴展卡來說，這兩個參數確實經常能救場。更穩妥的做法是先看 dmesg，判斷是中斷問題還是鏈路省電問題，再決定單獨使用還是一起使用。

它們是排障工具，不是硬體品質的替代品。如果加上參數後系統穩定了，說明問題大機率在中斷相容性或 PCIe 電源管理上；如果仍然掉盤，就要繼續檢查供電、線材、散熱、硬碟健康和擴展卡本身。

硬碟大漲價，NAS 滿了先別擴容：200 元鐵威馬 + HC620 冷資料方案

Mon, 04 May 2026 11:46:53 +0800

硬碟價格上漲時，NAS 空間滿了不一定要立刻擴容。尤其是主 NAS 還在正常工作、只是容量接近用完的情況下，更適合先把資料分層：原 NAS 只保留經常存取的熱資料，不常用的冷資料和備份卸到單獨的冷儲存碟。

這篇記錄的是一個低成本方案：用 HC620 這類大容量碟保存冷資料，再用便宜的鐵威馬 F2-220、F2-221 或 F4 機型做搬運和掛載節點。它不追求效能，只解決一個問題：在當前不適合升級硬碟的階段，先把主 NAS 的空間騰出來。

思路

整理資料時可以先按存取頻率分層：

熱資料：照片、工作資料、近期下載、經常播放的影片，繼續留在主 NAS。
冷資料：舊影視庫、歸檔資料、長期不動的大檔案，遷移到 HC620。
備份資料：只需要定期寫入、偶爾讀取的資料，也可以放到 HC620。

HC620 的使用場景可以參考站內文章：西部資料 HC620 疊瓦碟的誤區與正確使用方法。它更適合順序寫入、長期保存、隨機讀取，不適合頻繁刪除和反覆寫入的工作負載。

如果只是給主 NAS 騰空間，不建議在硬碟高價階段直接大規模替換主 NAS 硬碟。先把不常用資料卸出去，主 NAS 繼續負責熱資料，通常更划算。

為什麼用鐵威馬舊機器

HC620 的問題不是容量，而是使用不太方便。它對系統、介面和使用方式都有要求，直接插 USB 硬碟盒並不適合。

這時可以把鐵威馬 F2-220、F2-221 或部分 F4 機型當作低成本冷資料節點使用。優點很直接：

便宜，二手 F2-220 通常不超過 200 元。
體積小，不占地方，功耗也容易接受。
系統可以裝在 U 盤，不占用硬碟盤位。
有兩個或更多 SATA 盤位，適合掛 HC620 做歸檔碟。

這類舊機器效能不強，但做冷資料搬運、CIFS 掛載、背景複製已經夠用。F2-220 的 SATA 規格雖然比較老，只有 SATA 3G，但實測 HC620 在硬碟外圈對拷時仍然可以跑到約 200MB/s。對冷資料遷移來說，這個速度已經不慢，瓶頸更多時候反而在網路、來源碟狀態和檔案數量上。

如果對板載千兆網口速度不滿意，也可以加一個 USB 2.5G 網卡。冷資料節點不需要複雜改造，只要系統能識別網卡、交換器和主 NAS 也支援 2.5G，就能把網路瓶頸往上抬一截。

準備顯示輸出

如果機器沒有 HDMI 口，安裝系統時需要接 VGA。F2-220 機器內部預留了 VGA 介面，可以使用主機板內建 12Pin VGA 轉接線，一端接內部排針，另一端接標準 VGA 顯示器。

VGA 轉接線規格和注意點可以參考：鐵威馬 F2-220 安裝飛牛 OS：接 VGA 輸出。簡單說，搜尋關鍵詞可以用「12Pin VGA 轉接線」「主機板 12 針 VGA 轉接線」「2.0mm 12Pin 轉 VGA」，購買前要核對針距、方向和線序。

安裝 Ubuntu Server 到 U 盤

建議把 Ubuntu Server 裝到 U 盤，硬碟盤位全部留給資料碟。

F2-220 效能比較弱，直接在機器上安裝會很慢。更省事的方法是：把 U 盤插到另一台效能更好的電腦上完成 Ubuntu Server 安裝，裝完後再插回鐵威馬機器啟動。只要啟動模式相容，一般可以直接使用。

裝完後需要重點檢查網路設定，否則機器啟動後可能無法連網，也就無法 SSH 遠端管理。

設定網路

進入系統後，先查看網卡名稱：

`1`	`lshw -c network`

示例輸出裡可以看到 logical name：

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

這裡的網卡名是 enp2s0。然後編輯 netplan 設定檔：

`1`	`sudo more /etc/netplan/01-install-config.yaml`

如果檔案不存在，就新建一個，內容如下：

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

注意把 enp2s0 替換成自己機器實際看到的網卡名。保存後執行：

`1`	`sudo netplan apply`

網路恢復後，就可以透過 SSH 遠端連接這台鐵威馬機器，後續操作不需要一直接顯示器。

格式化 HC620 為 btrfs

如果 HC620 是新碟，或者碟上的資料已經確認不需要，可以先格式化為 btrfs。注意，下面的操作會清空目標硬碟資料，執行前一定要確認碟符，不要把主 NAS 共享目錄或系統 U 盤格式化掉。

先查看當前磁碟：

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

也可以查看更穩定的磁碟路徑：

`1`	`ls -l /dev/disk/by-id/`

確認 HC620 對應的裝置名後，卸載已有掛載點：

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

如果要把整塊碟直接做成 btrfs，可以執行：

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

這裡的參數含義：

-f：強制建立檔案系統，避免舊簽名阻止格式化。
-O zoned：啟用 zoned 特性，適合 HC620 這類需要按區域順序寫入的碟。
-d single -m single：資料和元資料都使用單碟模式。
-L HC620_01：設定卷標，方便識別。

如果你的系統或核心版本對 zoned btrfs 支援不理想，也可以繼續參考早期實測記錄裡的做法：某魚 600 元出頭西數 HC620 14T 的全新硬碟值得買嗎。這類碟的相容性和核心版本、SATA 控制器、檔案系統支援都有關係，遇到異常不要急著導入正式資料。

格式化完成後可以先臨時掛載測試：

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

確認可以正常掛載後，再寫入 /etc/fstab 做開機自動掛載。長期使用時更建議用 /dev/disk/by-id/ 路徑替代 /dev/sda，避免重啟後碟符變化。

設定掛載

這個冷資料節點通常需要同時掛載兩類路徑：

主 NAS 的共享目錄，用來讀取待遷移資料。
本機 HC620 資料碟，用來保存冷資料和備份。

先建立掛載目錄：

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

如果要掛載 CIFS/SMB 共享，需要安裝工具：

1
2

sudo apt update
sudo apt install cifs-utils

然後編輯 /etc/fstab，加入類似內容：

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

第一行用於掛載主 NAS 的共享目錄，後兩行用於掛載本機硬碟。

實際使用時建議優先用 /dev/disk/by-id/ 這類穩定路徑掛載資料碟，避免重啟後 /dev/sda、/dev/sdb 順序變化。HC620 的格式化和掛載注意事項可以參考早期記錄：某魚 600 元出頭西數 HC620 14T 的全新硬碟值得買嗎。

修改後可以先測試掛載：

1
2

sudo mount -a
df -h

確認主 NAS 共享目錄和本機資料碟都出現後，再開始遷移資料。

背景複製檔案

大量資料遷移不建議直接在 SSH 前台跑普通 cp。這裡優先推薦 screen + mc：screen 用來保證 SSH 斷開後任務不丟，mc 用來提供更直觀的雙欄檔案管理介面。

mc 的優勢是非常適合手動整理冷資料：左側打開主 NAS 掛載目錄，右側打開 HC620 資料碟目錄，選中檔案後按 F5 就能複製。複製過程中會顯示當前檔案進度和總進度，遇到大量檔案時比單純看命令列輸出更直觀。

上圖為複製檔案時的進度窗口示意。Midnight Commander 官方手冊也說明，複製、移動、刪除操作在 verbose 模式下會顯示檔案操作對話框，並可顯示當前檔案和總量進度。

安裝工具：

`1`	`sudo apt install screen mc rsync`

啟動背景會話：

`1`	`screen -S cold-data`

進入 screen 後直接執行：

mc

常用方式是左右兩欄分別進入來源目錄和目標目錄，然後用快捷鍵操作：

Tab：切換左右面板。
Insert：選擇多個檔案或目錄。
F5：複製到另一側面板。
F6：移動或重新命名。
F8：刪除，謹慎使用。

如果需要更適合腳本化、可重複執行的同步任務，再用 rsync：

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

複製過程中即使 SSH 斷開，screen 會話也還在。重新連接後執行：

`1`	`screen -r cold-data`

就能回到原來的複製任務。

使用建議

這個方案適合冷資料和備份，不適合把 HC620 當高頻寫入碟使用。建議按下面的方式使用：

主 NAS 繼續放熱資料和日常服務。
HC620 放長期保存的大檔案、影視庫、歸檔資料。
資料遷移以順序寫入為主，避免頻繁刪除和反覆小檔案寫入。
重要資料至少保留兩份，不要把唯一副本放在單塊碟上。
遷移完成後抽樣校驗檔案，確認目錄和檔案數量正常。

如果後續硬碟價格回落，再考慮升級主 NAS 陣列也不遲。當前階段先用低成本節點把空間壓力卸掉，風險和投入都更可控。

小結

NAS 空間滿了，不一定馬上買新碟擴容。把主 NAS 定位成熱資料設備，把 HC620 定位成冷資料和備份碟，再用便宜的鐵威馬 F2-220、F2-221 或 F4 機型做掛載和複製節點，是一個投入很低、落地性很強的過渡方案。

這個方案的關鍵不是效能，而是分工：主 NAS 保持日常體驗，冷資料單獨存放。這樣既能騰出空間，又能避開硬碟高價階段的大額升級成本。

鐵威馬 F2-220 安裝飛牛 OS：F3 背板、NVMe 與 BIOS 模組注入

Mon, 04 May 2026 06:09:40 +0800

這是一篇鐵威馬 F2-220 安裝飛牛 OS 的實踐記錄。目標是替換原廠 TOS，並在 F2-220 已停止官方支援的情況下繼續使用這台 NAS。過程中同時驗證了 F3 背板在 F2-220 上的可用性，並解決了 BIOS 不能從 NVMe 啟動的問題。

F3 背板原專案驗證設備是 F2-221，平台為 J3355；F2-220 是 J1800 平台，兼容性沒有現成結論。由於專案 fork 中已有 V1.1 版本，元件數量減少，成本和製作難度也下降，因此直接製作 V1.1 版本測試。

打板和焊接

背板專案地址：arnarg/f3_backplane。打板使用的是 fork 中的 V1.1 版本，核心目標是保留原有 SATA 硬碟位，同時從背板接口引出 NVMe 固態位置。

打板後拿到多塊 PCB。焊接時遇到一個細節：一開始沒有仔細看 BOM，焊完 M.2 後才發現 SATA 接口和常見接口不太一樣。

淘寶上沒有找到原生完全合適的 SATA 接口，最後選擇改現有接口：把針腳拔出並交換位置，再焊回板上，完成成品背板。

這一段的關鍵結論是：F3 背板方案在 F2-220 上可以繼續嘗試，但 SATA 接口選型需要特別注意，不要直接按常見 SATA 連接器下單。

接 VGA 輸出

F2-220 機器本身沒有外露影片輸出，但內部預留了 12 針 VGA 接口。需要購買主機板內置 12Pin VGA 轉接線，一端接機器內部 12 針排針，另一端通常是標準 DB15 VGA 母頭，用來外接顯示器。

常見搜尋關鍵詞可以用「12Pin VGA 轉接線」「主機板 12 針 VGA 轉接線」「2.0mm 12Pin 轉 VGA」。購買前要按機器內部接口照片核對插頭方向、針距和線序，不要只看「12Pin」字樣下單。

這一步對安裝很關鍵。沒有影片輸出時，後續 BIOS 和安裝過程會非常難排查。

安裝飛牛 OS

透過 Ventoy 啟動飛牛 OS 安裝程式。安裝介面可以成功看到 NVMe 固態，說明背板和 NVMe 硬體鏈路是通的。

但安裝完成後拔掉啟動碟，機器會重啟到 BIOS 介面，不能正常進入飛牛 OS。BIOS 啟動項裡沒有 NVMe 固態。把飛牛 OS 安裝到 U 盤啟動後，系統內又可以正常看到 NVMe。

這個現象說明：

NVMe 硬體識別沒有問題
Linux 系統內可以訪問 NVMe
失敗點在 BIOS 啟動階段
F2-220 平台較老，原 BIOS 很可能沒有 NVMe 啟動模組

備份 BIOS

此時已經可以用 U 盤啟動飛牛 OS，而飛牛 OS 基於 Debian，因此可以在系統內用 flashrom 備份和刷寫 BIOS。

刷 BIOS 有風險。最好準備編程器，避免刷壞後無法恢復。

安裝 flashrom：

1
2

sudo apt update
sudo apt install flashrom -y

確認是否能識別 BIOS 晶片：

`1`	`sudo flashrom -p internal`

機器識別到的晶片資訊類似：

`1`	`Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.`

備份原版 BIOS。注意命令中的晶片型號需要按自己的機器替換：

`1`	`sudo flashrom -p internal -c "W25Q64.W" -r backup_factory.bin`

注入 NVMe 模組

備份出的 BIOS 是一個 .bin 文件。可以透過 WinSCP 把文件傳到電腦上，再參考 B 站教程《讓老主板用上 Nvme 協議的固態》，把 NVMe 模組注入 BIOS 文件。

處理完成後，再把修改後的 BIOS 文件傳回飛牛 OS。

這裡不建議盲目套用別人的 BIOS 文件。不同機器、不同 BIOS 版本、不同 flash 晶片都可能有差異。更穩妥的做法是備份自己的原 BIOS，再基於自己的備份文件修改。

刷寫新 BIOS

刷寫命令如下。晶片型號、韌體路徑和文件名都要按實際情況替換：

`1`	`sudo flashrom -p internal -c "W25Q64.W" -w /vol1/NEW_NVME.bin`

當輸出中看到下面這行，表示校驗通過：

`1`	`Verifying flash... VERIFIED.`

刷寫完成後，BIOS 啟動項裡可以看到 PATA 項。對這類注入 NVMe 模組的老 BIOS 來說，NVMe 啟動項經常會以 PATA 形式顯示。看到它，說明 BIOS 已經可以識別 NVMe 啟動路徑。

結果

最終結果：

F3 背板 V1.1 在鐵威馬 F2-220 上可以識別 NVMe
飛牛 OS 安裝程式能看到 NVMe 固態
原 BIOS 不能直接從 NVMe 啟動
給 BIOS 注入 NVMe 模組後，啟動項出現 PATA
機器具備從 NVMe 啟動飛牛 OS 的條件

實測回饋裡也提到，這個 NVMe 通道速度只有 300MB/s 多。作為系統碟已經夠用，不需要上很好的 SSD，甚至小容量傲騰也能滿足需求。

注意事項

這不是普通無風險教程，更像一次硬體和 BIOS 改造記錄。真正動手前至少要注意：

F2-220 和 F2-221 平台不同，不能把 F2-221 的結果直接等同於 F2-220。
F3 背板需要打板和焊接，SATA 接口還可能需要改針腳。
機器內部 VGA 接口需要合適的轉接線，方便安裝和排錯。
BIOS 刷寫有變磚風險，最好提前準備編程器和原始備份。
flashrom 命令裡的晶片型號必須按自己機器識別結果填寫。
不要直接刷別人修改好的 BIOS，優先基於自己的備份注入 NVMe 模組。

這次記錄的價值在於補上了 F2-220 的實測結果：F3 背板思路不僅限於 F2-221，F2-220 也有機會使用 NVMe 系統碟；真正的卡點不在 Linux 識別 NVMe，而在 BIOS 是否支援 NVMe 啟動。

鐵威馬 F2-221 NAS 背板 pinout 記錄

Mon, 04 May 2026 06:02:56 +0800

這篇記錄整理鐵威馬 F2-221 NAS 背板連接器的非標準 pinout。這個介面外形接近 PCIe 邊緣連接器，但並不是標準 PCIe 插槽，而是鐵威馬自訂背板介面。

該連接器同時承載 SATA、電源、復位和 PCIe 訊號。確認 PCIe1 x1 可用後，可以透過自製背板接出 M.2 M-key 插槽，用 NVMe SSD 作為內部系統碟。

同一思路也適用於鐵威馬 F2-220。F2-220 與 F2-221 平台不同，但已有飛牛論壇實測：F3 背板 V1.1 在 F2-220 上可以識別 NVMe，安裝飛牛 OS 時系統內可見該 NVMe 碟；真正需要額外處理的是老 BIOS 可能不支援從 NVMe 啟動。

結論

F2-221 背板連接器裡同時包含：

兩個原生 SATA 埠的訊號
12V、5V、3.3V 和 GND
SATA 硬碟供電控制相關訊號
PERST#
至少一組可用的 PCIe Gen2 x1 訊號
第二組 PCIe 訊號的部分線索，但沒有完整驗證

PCIe1 可用於接出 M.2 M-key NVMe 插槽。實測中，NVMe 碟運行在 PCIe Gen2 x1 上，BIOS 可以識別並啟動。

F2-220 的實測結果也支持這個方向：硬體層面可以識別 NVMe，但 BIOS 啟動階段可能需要注入 NVMe 模組，啟動項可能以 PATA 形式出現。

背板連接器 pinout

連接器分為 B/A 兩側。? 表示未確認或未連接，NC 表示未連接。

Pin	B side	A side
1	12V	?
2	12V	12V
3	12V	12V
4	GND	GND
5	SATA1 A+	SATA1 B+
6	SATA1 A-	SATA1 B-
7	GND	NC
8	5V	5V
9	5V	5V
10	?	5V
11	?	?
12	3.3V	GND
13	GND	3.3V
14	SATA2 A+	3.3V
15	SATA2 A-	GND
16	GND	SATA2 B+
17	PERST#	SATA2 B-
18	GND	GND
19	PCIe1 TX+	NC
20	PCIe1 TX-	GND
21	GND	PCIe1 RX+
22	GND	PCIe1 RX-
23	PCIe1 REFCLK+	GND
24	PCIe1 REFCLK-	GND
25	GND	PCIe2 RX+
26	GND	PCIe2 RX-
27	PCIe2 TX+	GND
28	PCIe2 TX-	GND
29	GND	PCIe2 REFCLK+
30	?	PCIe2 REFCLK-
31	?	GND
32	GND	?

PCIe1 的參考價值更高。PCIe2 未完整驗證，只適合作為線索，不能直接作為可靠設計依據。

訊號來源判斷

F2-221 原廠雙碟背板沒有 PCIe 轉 SATA 控制器，SATA 訊號直接從主機板連接器進入背板。額外 PCIe 訊號主要從同系列多碟位機型推斷而來。

鐵威馬 F5-422 背板使用兩顆 ASMedia ASM1061。ASM1061 是 PCIe Gen2 x1 轉雙 SATA 控制器。結合 Intel J3355 本身有 2 個 SATA 埠和 6 條 PCIe Gen2 lane，可以推斷多碟位型號透過 PCIe 擴展 SATA 連接埠。

因此，F2-221 主機板連接器上保留 PCIe 訊號是合理的。廠商很可能在同系列不同碟位機型之間複用主機板設計，只透過背板區分功能。

PCIe 差分對判斷

PCIe 差分線進入過孔後通常會走內層，無法只靠照片完整追線。一個可用判斷規則是：傳統 PCIe 設計中，TX 差分對通常帶 AC coupling 電容。

方向需要反過來看：

從 ASM1061 控制器角度看的 TX，對應 CPU 或主機板側的 RX
從 ASM1061 控制器角度看的 RX，對應 CPU 或主機板側的 TX
REFCLK 需要結合相鄰差分對和走線位置判斷

這類 pinout 更適合當作硬體逆向資料，而不是官方規格書。

可用性驗證

基於這份 pinout 製作的 F3 背板已經完成過以下驗證：

原有兩個 SATA 硬碟位繼續可用
PCIe1 可接到 M.2 M-key 插槽
NVMe SSD 可被 BIOS 識別
NAS 可以直接從 NVMe SSD 啟動
btrfs scrub 未發現硬碟錯誤
系統從 NVMe SSD 運行數週無明顯異常

測試用 NVMe SSD 為 Patriot P300 128GB。hdparm 結果如下：

1
2
3

/dev/nvme0n1:
 Timing cached reads:   4554 MB in  2.00 seconds = 2279.68 MB/sec
 Timing buffered disk reads: 1222 MB in  3.00 seconds = 407.22 MB/sec

這個速度符合 PCIe Gen2 x1 的限制。它不是為了跑滿 NVMe 性能，而是作為內部系統碟替代外接 USB SSD。

注意事項

這份 pinout 適合作為硬體逆向和自製背板參考，但不應當成官方資料使用。

連接器不是標準 PCIe，不能直接插通用 PCIe 裝置。
? 腳位未確認，不應隨意接入關鍵電路。
PCIe2 未完整驗證，風險比 PCIe1 更高。
CLKREQ 沒有按常規 M.2 設計完整接出，ASPM 可能不可用。
SATA 供電包含熱插拔相關的 load switch 和 slow start 邏輯，不能只接訊號線而忽略供電控制。
如果要複刻，應重新測量自己的主機板和背板，不要只依賴照片。

Seagate Exos 2X14 雙臂硬碟：便宜的大容量高速碟，也有很高使用門檻

Fri, 01 May 2026 11:05:45 +0800

Seagate Exos 2X14 / Mach.2 是一類很特別的企業級機械硬碟。它的核心賣點不是單純容量，而是雙臂結構：一顆 14TB 硬碟在系統裡會被識別成兩顆 7TB 邏輯碟，每一側都有獨立的磁臂和磁頭組件，可以並行讀寫。

這讓它在二手市場上顯得很誘人。在一些行情裡，普通 14TB 企業碟價格已經被炒高，而這類退役雙臂碟可能以更低價格拿到 14TB 容量，還能在順序讀寫裡跑出接近 SATA SSD 的速度。但這顆碟不是普通 NAS 使用者隨手就能買來替換的硬碟。它的優勢和風險都很鮮明，買之前必須先弄清楚。

它為什麼能跑得這麼快

普通機械硬碟只有一套磁臂和磁頭，同一時間主要由一組磁頭負責讀寫。 Exos 2X14 / Mach.2 則把一顆硬碟拆成兩個 7TB 邏輯單元，兩組磁臂可以同時工作。

單個 7TB 邏輯碟的連續讀寫大約在 250MB/s 左右，和常見大容量企業碟接近。如果把兩個 7TB 邏輯碟組成 RAID 0，在沒有網路瓶頸的情況下，大檔案順序讀寫可以接近 500MB/s。這個速度已經接近主流 SATA 固態硬碟，也足以把 2.5G 網路跑滿。

不過，這個提升主要體現在大檔案順序讀寫。 4K 小檔案、碎片檔案、隨機存取不會因為雙臂結構和 RAID 0 就突然起飛。本質上它仍然是機械硬碟，小檔案場景該慢還是慢。

最大門檻是介面和硬體環境

市面上容易買到的低價版本大多是 SAS 介面退役伺服器碟，而不是 SATA 版本。這意味著它不適合直接塞進大多數成品 NAS。

綠聯、群暉、威聯通這類品牌 NAS 的背板通常面向 SATA 硬碟設計，SAS 碟多數情況下無法直接使用。 DIY NAS 使用者也需要額外準備硬體條件：

主機板要有可用的 PCIe 插槽
需要 SAS HBA 或陣列卡，常見如刷 IT 模式的 LSI 2008
需要伺服器 SAS 背板，或者 SFF-8087 轉 SFF-8482 之類的轉接線
系統要能正確識別同一顆物理碟拆出的兩個邏輯碟

陣列卡本身不一定貴，麻煩主要在整套連接和相容性。如果機器空間、電源線、背板、散熱和 PCIe 插槽都不富裕，這顆碟會明顯增加折騰成本。

不要把兩個 7TB 當成互相備份

這類硬碟最容易踩的坑，是把系統裡顯示出來的兩個 7TB 邏輯碟當成兩顆獨立硬碟。它們不是兩顆物理碟，只是同一顆物理硬碟的兩個邏輯單元。

如果把這兩個 7TB 邏輯碟組成 RAID 1，看起來像是互相鏡像，實際意義很有限。因為它們共享同一個外殼、主機板、電源介面和部分機械環境。一旦物理碟本體、控制板或供電路徑出問題，原始資料和所謂備份會一起離線。

RAID 5、RAID 6 也要非常謹慎。傳統 RAID 5 通常只容忍一顆物理硬碟故障，但雙臂硬碟壞掉時，陣列層面可能等同於同時丟失兩個 7TB 邏輯碟。如果陣列設計沒有考慮這種故障模型，容錯機制很容易被擊穿。

所以，這類碟更適合被理解為一顆高速但風險集中的大容量碟，而不是兩顆可互相冗餘的硬碟。

NAS 系統裡的正確姿勢

如果硬體直通和驅動識別都正常，FNOS、TrueNAS、Unraid、Windows 等系統通常都能看到兩個 7TB 邏輯碟。關鍵不是能不能識別，而是怎麼用。

在 FNOS 裡，可以把兩個 7TB 邏輯碟建立為 RAID 0 儲存空間，用來換取順序讀寫速度。

在 TrueNAS 裡，新建儲存池時可能會提示是否允許使用同序列號硬碟。如果確認要使用這顆碟，可以允許後將兩個邏輯碟放進同一個 vdev，並選擇 Stripe，而不是 Mirror。 Mirror 會製造一種並不可靠的冗餘錯覺。

在 Unraid 裡，不建議把這兩個邏輯碟塞進帶校驗碟的主陣列。更合理的方式是單獨建立一個快取池或專用高速池，用 Btrfs 或 ZFS 做獨立 RAID 0，讓它承擔高速臨時資料、下載、轉碼快取、可重建資料等任務。

Windows 下也可以識別並使用，思路類似：可以做條帶提升順序效能，但不要把它當成真正的雙碟備份方案。

還要考慮壽命、溫度和功耗

雙臂結構帶來效能提升，也帶來更複雜的機械結構。這類硬碟內部有兩套磁臂和更多磁頭組件，機械風險點自然更多。再加上二手市場常見的是退役企業碟，實際使用時長、通電時間、歷史負載和運輸狀態都不透明，不能只看規格表上的壽命指標。

功耗和散熱也不能忽視。滿載時功耗可能超過 11W，外殼溫度上 40 多度並不罕見。如果安裝在散熱不好的小機箱、密集硬碟籠或低風量 NAS 裡，長期高溫會進一步影響穩定性和壽命。

適合誰買

這顆碟適合願意折騰 DIY NAS、有 SAS 硬體條件、明確知道 RAID 0 風險，並且主要處理大檔案順序讀寫的人。例如影音庫、下載快取、臨時素材碟、可重新生成的資料池，都可以發揮它的容量和速度優勢。

它不適合以下場景：

成品品牌 NAS 使用者
不想額外購買 SAS 陣列卡和轉接線的使用者
對資料安全要求很高的主儲存
想把兩個 7TB 邏輯碟做 RAID 1 當備份的使用者
主要跑小檔案、虛擬機隨機讀寫或資料庫負載的使用者

如果目標是低價大容量和高速順序讀寫，Exos 2X14 / Mach.2 確實有可玩性。但它的正確定位應該是「便宜、快、能折騰的專用碟」，而不是「閉眼上車的萬能 NAS 碟」。

硬碟有價，資料無價。這類雙臂碟可以買，但最好只放可恢復、可重建、已經另有備份的資料。真正重要的資料，仍然應該放在清晰可靠的備份策略裡。

16核板U為什麼這麼便宜：Xeon D-1581 這類一體板到底值不值得買

Wed, 29 Apr 2026 10:48:00 +0800

最近這類 Xeon D-1581 板 U 一體板又開始有人聊，原因也很簡單：價格確實太有誘惑力了。

你很容易看到這種賣點：

16 核 32 執行緒
板 U 一體
多網口
有 PCIe
價格低得很誇張

只看參數，它確實很像 NAS、AIO、下載機、家庭實驗室的神板。
但這類板值不值，關鍵不在「核心數多不多」，而在 你的用途對不對。

先說結論

這類板的優點很直接：

核心數多
一體板省事
擴充通常比小主機強
掛很多後台服務會很舒服

缺點也很直接：

平台很老
單核性能一般
穩定性和相容性看板子體質
很多低價貨本質上是老平台風險轉手

所以它適合折騰，不適合幻想。
你要是明確拿來做 NAS、容器機、實驗室主機，它可能很值；你要是想低價買台省心主力機，那大概率會失望。

為什麼這類板會讓人心動

原因很簡單：它把幾個很容易打動人的點疊在了一起。

16 核 32 執行緒
多網口和 PCIe
主機板和 CPU 一起給你
老伺服器平台下放之後價格很低

同樣的錢，桌面平台也許只能買到普通 4 核、6 核，這邊卻給你 16 核 32 執行緒。
這就是它最危險的地方：它賣的其實是「執行緒數和介面感」，不是完整體驗。

優點

1. 掛服務確實舒服

這類板最適合：

NAS
Docker 宿主機
下載機
家庭實驗室
輕中負載虛擬化

它不是單個任務特別快，而是適合一台機器上同時掛很多東西。

2. 擴充比很多小主機好

如果你需要：

加網卡
加 HBA
加儲存轉接卡
自己折騰儲存和網路玩法

那這類板通常比迷你主機更有意思。

3. 板 U 一體，搭起來快

不用單獨配 CPU 和主機板，也少了很多相容性猜謎。
對折騰黨來說，這一點很實用。

缺點

1. 平台老

這是最大的前提。
老平台意味著單核一般、介面規格舊、功耗和效率也別期待太現代。

2. 不適合當前台主力機

16 核 32 執行緒聽起來很猛，但這類板更像後台苦力，不像日常主力機。
你拿它當桌面主機，體感通常不會讓你開心。

3. 便宜往往帶著風險

這類板最常見的問題不是點不亮，而是：

板子來源雜
BIOS 和相容性不穩定
記憶體、網卡、PCIe 設備可能挑
長期穩定性要自己驗證

說白了，這類板便宜，不等於省事。

4. 功耗未必真低

很多人會把它腦補成「執行緒多、功耗低、很適合 24 小時開機」。
實際沒這麼輕鬆，整機表現很看板子設計、散熱和你掛了多少設備。

這類板最適合什麼人

適合的人很明確：

想低成本搭一台 NAS
想做家庭實驗室
想掛很多容器或服務
能接受舊平台，也願意自己排問題

不太適合什麼人

不太適合的人也很明確：

想把它當主力桌面機
想低價買一台省心機器
特別在意功耗、靜音、售後
不想自己排錯

最後一句

Xeon D-1581 這類板不是不能買，而是 只能在對的用途裡顯得很值。

你要的是多執行緒、介面、擴充和長期掛服務，它很有吸引力。
你要的是新平台、強單核、省心和主力機體驗，那它多半不適合。

最短結論就是：

優點是執行緒多、介面多、擴充多；缺點是平台老、體質雜、折騰多。

NAS on KnightLi的博客

Syncthing 多設備多資料夾怎麼管理？拓撲、命名和版本控制

Syncthing 系列目錄

拓撲：放棄全連接，優先星型

Folder ID 比資料夾標籤更重要

中心節點路徑要規範

引入者：減少多設備配對成本

區分備份和雙向同步

手機照片備份

多端文件和筆記

資料分發

備份目錄

NAS 上開啟檔案版本控制

用忽略規則過濾暫存檔案

多資料夾命名範例

推薦整體方案

總結

Syncthing 如何同步 iPhone 照片到電腦或 NAS

Syncthing 系列目錄

先理解 iOS 上的限制

第一步：安裝客戶端並授予權限

通知權限

本機網路權限

相簿存取權限

第二步：iPhone 和電腦/NAS 配對

第三步：在 iPhone 上建立相簿同步資料夾

第四步：iPhone 端設為 Send Only

第五步：在電腦或 NAS 端接收照片

接收端建議設為 Receive Only

iOS 背景同步的現實限制

避免 iCloud 最佳化儲存影響同步

大量照片首次同步建議

推薦配置

總結

Android 上怎麼用 Syncthing？Syncthing-Fork 設定與照片備份

Syncthing 系列目錄

為什麼更推薦 Syncthing-Fork

安裝來源

第一步：授予必要權限

儲存權限

電池最佳化白名單

第二步：和 NAS 或電腦配對

第三步：接收 NAS 或電腦共享的資料夾

第四步：把手機照片備份到電腦或 NAS

手機端新增相簿資料夾

手機端改為 Send Only

接收端設定保存路徑

接收端改為 Receive Only

第一次同步前先小規模測試

執行條件：防止偷跑流量

充電時同步：更省電的工作流

Android 11 之後的儲存限制

手機端資料夾類型怎麼選

筆記雙向同步

手機照片備份到 NAS

手機只看資料

刪除策略要想清楚

常見問題

鎖屏後不同步

找不到相簿目錄

同步很慢

刪除手機照片後 NAS 也刪了

推薦設定

總結

Syncthing 多設備怎麼配置？對等網路、星型拓撲和引入者

Syncthing 系列目錄

先理解「對等」和「偽伺服器」

模式一：純對等 Mesh 網路

模式二：以 NAS 為中心的星型拓撲

多設備配置的基本順序

第一步：設備互聯

第二步：建立並共享資料夾

第三步：接收共享

星型拓撲怎麼配置

引入者是什麼？

資料夾類型決定資料方向

Send & Receive

Send Only

Receive Only

不同目錄可以用不同拓撲

`.stignore` 要放在同步根目錄