FTP、SFTP 與 FTPS：差別到底在哪？

FTP、SFTP 與 FTPS 看起來像是同一種東西的三種口味，而這些名字也確實讓人更容易搞混。實際上，其中一個是 1970 年代的協定、密碼以明文傳送；一個是同一個協定外面包了 TLS；還有一個是完全不同的協定，只是借用了那幾個字母。如果主機控制台或 NAS 設定畫面正要你挑一個，以下就是每個選項真正的意思。

簡短的答案：只要伺服器支援，就用 SFTP。它把所有東西都加密，只需要一個連接埠，而且能乾淨俐落地穿過防火牆。當你被綁在加了 TLS 的 FTP 基礎架構上時，才用 FTPS。至於純 FTP，只有在提供公開、非敏感的下載時才用 — 或者乾脆別用。

FTP：最原始的那個，而且沒有加密

FTP（檔案傳輸協定）可以追溯到網際網路最早的年代，它透過兩條通道運作：一條是連接埠 21 上的控制連線，用來傳送指令；另一條則是每次傳檔或列出目錄時另外建立的資料連線。全程沒有加密 — 你的使用者名稱、密碼與檔案內容，在網路上任何處於監看位置的人眼中都是可讀的。

這種雙連線設計，也造成了 FTP 惡名昭彰的防火牆問題。在主動模式下，伺服器會反過來連回用戶端（通常會被擋）；在被動模式下，用戶端則要另外連到伺服器上一個隨機的高編號連接埠（除非伺服器防火牆開放了被動連接埠範圍，否則也會被擋）。如果你曾經順利登入，然後眼睜睜看著目錄列表永遠卡在那裡，原因就是這個 — 我們談2026 年 FTP 還有什麼立足之地的文章，說明了它為什麼依然存活下來。

FTPS：在 FTP 上外掛 TLS

FTPS 就是加上 TLS 加密的一般 FTP — 和瀏覽器網址列上那把鎖用的是同一套技術。它有兩種形式：明確式 FTPS，用戶端連到一般的連接埠 21，再用 AUTH TLS 指令把連線升級為加密（這是標準做法，定義在 RFC 4217）；以及隱含式 FTPS，一種較舊的慣例，在連接埠 990 上從第一個位元組就開始加密。

伺服器會用 TLS 憑證證明自己的身分，就跟網站一樣。但 FTPS 沒有解決的是雙連線架構 — 資料仍然走另外的連線，所以被動連接埠那套防火牆麻煩事依舊存在，而且更棘手，因為防火牆再也無法窺看（現在已加密的）控制通道來自動開放資料連接埠。

SFTP：根本不是 FTP

SFTP（SSH 檔案傳輸協定）和前面兩個只共用了四個字母，其他毫無關係。它是建立在 SSH 之上的檔案傳輸協定 — 也就是管理員用來連遠端終端機的那條安全通道。所有東西 — 驗證、指令、檔案資料 — 都加密後在連接埠 22 上的同一條 SSH 連線裡傳送。

正是這種單一連線的設計，讓 SFTP 穿過防火牆與 NAT 時如此順利：開一個連接埠就沒事了。驗證可以用密碼，或者更好的做法是用 SSH 金鑰，這也是 SFTP 成為自動化部署與腳本傳輸首選的原因。伺服器不是用憑證，而是用主機金鑰來證明身分，用戶端會記住它的指紋 — 一旦有變動就會警告你。

並列比較

你該用哪一個？

• 你可以自由選擇時：SFTP。最穩健的預設值、最單純的網路設定，還能用金鑰做自動化。
• 你的主機或設備只支援 FTP／FTPS：用 FTPS 的明確模式，並確認憑證有效。只有在資料真的是公開的情況下，才用純 FTP。
• 你要做自動化：用 SFTP 搭配 SSH 金鑰 — 別把密碼寫進腳本。（在 Windows 上要注意，內建的 ftp.exe 既不支援 SFTP 也不支援 FTPS — 它的限制請見我們的命令列 FTP 指南。）
• 法規要求「FTPS」：有些支付與醫療相關的規範會明確指名 FTPS；除此之外，FTPS 與 SFTP 都能滿足傳輸過程加密的要求。

不確定某台伺服器實際支援什麼？用我們的免費測試工具對它跑一次：FTP、SFTP 與 FTPS 連線測試工具會從你的瀏覽器實際跑一次交握，而 TLS 協定掃描器則會顯示某台 FTPS 伺服器能協商出哪些 TLS 版本。

或者，乾脆不用選

三種協定在實務上真正惱人的地方，是你得去在意每台伺服器講的是哪一種。一個現代的用戶端會讓這個差別變得無關緊要：FTPie 能在同一個視窗裡連上 FTP 與 FTPS，也能連 SFTP 伺服器（外加 WebDAV 與 10 種以上雲端服務），被動模式與主機金鑰驗證都幫你處理好，而且免費方案涵蓋最多 3 個伺服器連線 — 足以讓你不必再想那些縮寫，專心搬檔案就好。

習慣從終端機操作？把指令參考放在手邊：FTP 指令與 SFTP 指令，都附有語法與範例。