一、 概念了解
FTP的主動、被動模式讓人很煩，相信你認真看完下面的描述就不會再煩了！
由于曆史原因，FTP服務預設需要有2個端口20（資料端口）,21（控制端口）
FTP服務的最初的工作過程是：Client請求Server的21端口建立控制連接配接，然後Server主動用20端口去連Client建立資料連接配接，結果總是被Client的防火牆拒之門外。（主動模式）
Server畢竟是為大多數人服務的，這樣低三下四又幹不成事固然不行，于是為了解決服務端被拒之門外的問題，被動模式誕生了：Client請求Server的21端口建立控制連接配接，然後Server告訴Client我開了哪幾個資料端口，你自己來連。（被動模式）
2種模式的差別總結為一句話：前提都是Client去請求Server建立控制連接配接，不同的是誰來發起資料連接配接。
二、 故障分析案例
FTP伺服器公網IP為：124.x.x.x 内網IP：192.168.1.85 服務端為Vsftpd
故障如圖（連接配接逾時）：
當我看到這個問題的時候，我并不知所措，也沒有仔細去分析連接配接的過程，我習慣性的用工具連接配接了一下，因為我相信工具某些方面比人更強大，果然我用CuteFTP連接配接正常，于是我看工具連接配接的日志，注意到了一句話：
這句話是什麼意思呢？為什麼要替換呢？
我們來分析一下過程：
Client向Server（公網IP）發出控制連接配接申請并通過賬号密碼驗證
Client向Server發出PASV指令進入被動模式
Server向Client傳回的是監聽IP（192.168.1.85）和資料傳輸端口（38*256+252=9980）
Client發現傳回的IP（192.168.1.85）和之前發出的連接配接（124.x.x.x）不同，Client自行修改IP為正确的公網IP
Client向124.x.x.x的9982端口發出資料連接配接申請，建立資料連接配接
這個分析完之後，我們再回過頭來看用指令連接配接時出現的問題，不難看出，是卡在了Client向Server端發出資料連接配接申請的時候了，為什麼？因為我們指令模式不是智能的，不會自己将Server傳回的内網IP轉成公網IP，是以連192.168.1.85傳回逾時。
然後分析的就是為什麼會隻傳回内網IP？
原來，公網IP并不是配在該服務端的，而是通過路由進行綁定的，例如雲主機上的“彈性IP”等，是以FTP服務端程式隻知道存在一個内網的IP。
解決辦法：配置檔案寫入pasv_address=公網IP
# man vsftpd.conf