遠端連線與同步工具選型:連得穩、斷得起、檔案一致
遠端工作有三塊彼此獨立的能力:保住 session(多工器讓遠端的工作不隨連線消失)、連線層(決定你怎麼接上遠端、斷了怎麼辦)、同步層(決定本地與遠端的檔案怎麼保持一致)。多工器是地基、已在遠端工具總覽談過;這篇補另外兩塊——連線用什麼、檔案怎麼同步。這三塊要分開看,因為它們解的是不同問題,混在一起挑會挑錯:session 掉了是多工器的事,打字延遲高是連線層的事,本地改了遠端沒更新是同步層的事。
連線層:從 SSH 出發,按弱點往上補
連線層的基準是 SSH——它是遠端登入的通用標準,加密、認證、port forwarding 都靠它,多數情況直接用 SSH 就夠。往上補工具的時機,是 SSH 在特定弱點上讓你難受的時候,而不是「有更潮的工具就換」。SSH 的兩個典型弱點是「網路一換就斷」(筆電休眠、Wi-Fi 換點、行動網路切換)和「連線中斷後要手動重連」,mosh 與 autossh 各補一個。
| 工具 | 解的問題 | 代價 | 何時值得換 |
|---|---|---|---|
| SSH | 通用遠端登入基準 | 網路一換 IP 就斷、休眠喚醒常要重連 | 預設就用它 |
| mosh | 漫遊不斷線、高延遲下打字順 | 走 UDP 要開額外 port、不支援 port forwarding | 行動網路 / Wi-Fi 換點 / 高延遲 |
| autossh | SSH 斷線自動重連 | 只是重連、session 內容還是靠多工器保住 | 需要一條長期自動維持的隧道 |
mosh:換網路不掉線、高延遲下還能打字
mosh(mobile shell)解的是「連線的存活與手感」:它在 SSH 之上用 UDP 維持一個跟客戶端 IP 無關的 session,所以你的筆電從家裡 Wi-Fi 換到行動網路、或休眠喚醒換了 IP,連線不會斷。它還做本地回顯預測,高延遲鏈路上打字不會有一個字一個字等回應的黏滯感。從咖啡廳、通勤、跨國高延遲連遠端時,mosh 的體驗明顯優於裸 SSH。
它的代價是走 UDP,要在遠端開一段 UDP port 範圍(防火牆/雲端 security group 要放行),且不做 SSH 的 port forwarding——需要轉發本地端口時還是得另開一條 SSH。所以 mosh 通常跟多工器搭配用:mosh 保住連線手感、多工器保住 session 內容,兩者互補。
autossh:維持一條會自己重連的隧道
autossh 解的是「隧道的自動存活」:它監控一條 SSH 連線,斷了就自動重建,適合需要長期維持的場景——例如把遠端某個服務 port forward 回本地、或維持一條反向隧道讓 NAT 後的機器可被連入。它本身只負責「重連」這個動作,重連後你原本的工作是否還在,取決於你有沒有用多工器把 session 保住。
判讀:autossh 是「基礎設施型」工具,用在你要一條無人值守、掉了要自己回來的隧道;日常互動式登入用 mosh 的漫遊能力更順。兩者不衝突。
網路層:機器根本連不到時,先解可達性
前面的連線工具都假設「遠端機器的 IP 你連得到」。當遠端機器在 NAT 或防火牆後面、沒有公開 IP 時,連不到是可達性問題,要在網路層解,而不是換 SSH 客戶端。WireGuard 是現代的輕量 VPN 協定,讓兩台機器像在同一個私網裡直接互連;Tailscale 建在 WireGuard 之上,把「交換金鑰、打洞穿透 NAT、管理裝置清單」這些麻煩事自動化,通常裝好登入就能讓你的所有裝置互相 SSH,不必自己配 VPN。
判讀:家裡的機器、公司內網的開發機、雲端私網裡的主機,想從外面連進去又不想開公網 port 暴露 SSH,用 Tailscale(要省事)或自建 WireGuard(要完全自主、不依賴第三方協調伺服器)在網路層打通,之後 SSH/mosh 照常用。這一層跟連線層是疊加關係:先有可達性,上面才談連線手感。(機器連不到的診斷——是網路層、服務層還是機器沒起——見機器連不到或起不來。)
同步層:三種語義,依 workflow 選
檔案同步不是一個問題,是三種不同語義的問題,挑錯工具會很痛。核心差異在「同步是單向還是雙向、是一次性快照還是持續即時、檔案存在本地還是遠端」。rsync、sshfs、mutagen 各自代表一種語義:
| 工具 | 語義 | 檔案實際在哪 | 適合的 workflow |
|---|---|---|---|
| rsync | 單向、一次性快照、增量傳輸 | 兩邊各一份 | 部署、備份、把成果拉回來 |
| sshfs | 把遠端目錄掛載成本地路徑 | 只在遠端 | 偶爾存取遠端檔案、當本地資料夾用 |
| mutagen | 雙向、持續、即時同步 | 兩邊各一份即時 | 本地編輯、遠端執行的開發迴圈 |
rsync:單向增量,部署與拉回成果的正典
rsync 解的是「把一批檔案有效率地從 A 複製到 B」:它只傳有變動的部分(增量),可保留權限與時間戳,是單向的一次性動作——你下指令、它同步一次、結束。它適合明確的「推上去」或「拉回來」:把本地建好的東西部署到遠端、把遠端跑完的產出拉回本地、定期備份。它不做「持續盯著兩邊、誰改了就同步」,所以拿它當即時開發同步用會很累(每次改都要手動跑)。
因為單向且明確,rsync 也是三者裡最可預測、最不會意外覆蓋的——你清楚知道哪邊是來源、哪邊被更新。無人值守的成果回收(遠端跑完長任務、把結果 rsync 回本地)用它最穩。
sshfs:把遠端目錄當本地資料夾掛載
sshfs 解的是「我想用本地的工具存取遠端的檔案、但不想先複製下來」:它透過 SSH 把遠端目錄掛載成本地的一個路徑,你用本地的編輯器、檔案管理員直接開,實際檔案仍只在遠端。適合偶爾存取、檔案不宜落地到本地的場景。
它的代價是脆與慢:每次存取都走網路,延遲高時開大目錄、跑 git status 這種大量小檔操作會很卡;連線一斷,掛載點就進入壞狀態要重掛。所以 sshfs 適合「輕度、偶爾」的遠端存取,不適合當重度開發的主力——重度開發本地要有一份真的檔案,那是 mutagen 的場景。
mutagen:雙向即時,本地編輯遠端執行的開發迴圈
mutagen 解的是現代遠端開發最常見的迴圈:「在本地用順手的編輯器改、在遠端(有算力、有環境、有相依)執行」,它在兩邊各保留一份實體檔案並持續雙向即時同步——你本地存檔,遠端幾乎同時更新;遠端產生的檔案也同步回本地。因為兩邊都是本地檔案,git status、搜尋、建置都快,沒有 sshfs 那種每次存取走網路的黏滯。
它的代價是多一個常駐同步 daemon 與初次設定,且雙向同步要處理衝突(兩邊同時改同一檔)。適合「本地機器弱/環境不對、但要在強遠端上跑」的長期開發關係。如果你的需求只是「偶爾拉個檔」,mutagen 是殺雞用牛刀,rsync 或 sshfs 更省。
IDE remote:把編輯器的執行環境整個搬到遠端
VS Code Remote(SSH/Containers/WSL)與 JetBrains Gateway 是另一條路線:它們不同步檔案,而是把編輯器的後端(語言伺服器、終端機、除錯器)整個跑在遠端,本地只留 UI。你在本地視窗編輯,但索引、建置、執行全發生在遠端那台機器上,檔案也只在遠端。這解掉了同步的衝突問題(沒有兩份檔案要對齊),代價是綁定該編輯器、且需要一條夠穩的連線維持 UI 與後端的通訊。
判讀:如果你本來就用 VS Code / JetBrains,remote 模式通常比自己接 mutagen + SSH 更省事、體驗更整合;如果你用終端機編輯器(Vim/Neovim/Emacs)或要編輯器無關的方案,走 mutagen(雙向同步)或直接在遠端多工器裡編輯(檔案只在遠端、靠多工器保住 session)。
在 Arch 上的安裝與依賴(實測 aarch64)
這些工具多數在官方 repo,但有幾個安裝陷阱與部署前提是實機才看得出來的,選好工具後要一起確認:
- mosh:官方 repo(
pacman -S mosh)。同一套件同時含 client(mosh)與 server(mosh-server),所以遠端機器也要裝 mosh——遠端是別人的伺服器時這是前提;另外 UDP 埠範圍(預設 60000–61000)要在防火牆 / security group 放行。 - autossh / rsync / sshfs:都在官方 repo(
pacman -S autossh rsync sshfs)。sshfs會自動拉fuse3相依,不用手動裝 FUSE;掛載需要/dev/fuse可存取(一般環境已就緒)。 - tailscale:官方 repo(
pacman -S tailscale),但裝完 daemon 預設沒起——要sudo systemctl enable --now tailscaled之後才能tailscale up。少了這步,tailscale指令會因 daemon 未運行而失敗。 - wireguard:裝
wireguard-tools(wg/wg-quick)。核心模組在多數發行版是 loadable module,wg-quick會在需要時自動modprobe wireguard,日常不用手動處理。 - mutagen:不在官方 repo,且
pacman -S mutagen會裝到完全無關的python-mutagen(音訊 metadata 函式庫)。正確安裝是 AUR 的mutagen.io-bin(paru -S mutagen.io-bin),提供mutagen執行檔,aarch64 有官方 binary。這是「以為一句 pacman 就有、實際會裝錯東西」的典型坑。 - VS Code Remote / JetBrains Gateway:綁各自的 IDE,不透過套件管理器單獨裝,隨 IDE 的 remote 擴充啟用。
依情境選
把上面的工具對回你的實際處境:
- 日常從筆電連遠端、常換網路:mosh(漫遊)+ 多工器(保 session)。
- 要一條長期自動維持的隧道 / 反向連接:autossh + 多工器。
- 遠端機器在 NAT 後、根本連不到:先用 Tailscale 或 WireGuard 在網路層打通,再照常 SSH/mosh。
- 部署上去、或把遠端跑完的成果拉回來:rsync(單向、可預測)。
- 偶爾存取遠端幾個檔、不想複製下來:sshfs(掛載)。
- 本地編輯、遠端執行的長期開發迴圈:mutagen(雙向即時)或你的 IDE 的 remote 模式。
- 無人值守跑長任務、跑完自動回收成果:多工器保住任務 + rsync 拉回產出,見讓機器跑無人值守的長任務。
判準是先分清「你缺的是連線存活、可達性、還是檔案一致」,再在對應那一層挑工具——三層各挑各的,不要拿同步工具去解連線問題。
下一步
- 保住遠端 session 的多工器(tmux / zellij)配置與比較:遠端工具總覽 與 CLI 環境工具 的多工器篇。
- 連不上、終端機噴亂碼、要從 SSH 操控圖形桌面等連線本身的問題:除錯與診斷:遠端連線與終端機問題。
- 機器完全沒回應、域名解析不了、虛擬機起不來:機器連不到或起不來。
- 把遠端機器設成無人值守、離開後自己跑完長任務送回成果:讓機器跑無人值守的長任務。