FTP 패시브 모드 연결 오류 및 방화벽 설정 해결 방법

FTP는 로그인되지만 디렉터리 목록을 불러올 때 멈추는 이유

FTP 패시브 모드는 FTP가 하나의 TCP 연결이 아닌 두 개의 TCP 연결을 사용하기 때문에 방화벽에서 차단됩니다. 포트 21에 대한 연결은 로그인과 명령을 처리하므로 사용자 이름과 비밀번호는 정상적으로 수락되고 방화벽 설정도 올바른 것처럼 보입니다. 이후 첫 번째 ls은 다른 포트에서 두 번째 연결을 필요로 합니다. 방화벽에 해당 연결을 허용하는 규칙이 없으면 클라이언트는 타임아웃이 발생할 때까지 대기 상태로 머뭅니다.

이 문제를 해결하려면 데이터 연결을 위한 포트 범위를 고정하고, 방화벽에서 해당 범위를 허용하는 규칙을 추가해야 합니다. NAT(네트워크 주소 변환) 뒤에 있는 서버는 올바른 주소를 알릴 수 있도록 추가 설정이 하나 더 필요합니다. 과거에는 연결 추적 헬퍼(connection tracking helpers)가 이 작업을 자동으로 수행했습니다. 하지만 더 이상은 그렇지 않으며, 오래된 가이드를 복사하기 전에 그 이유를 알아두는 것이 좋습니다.

제어 채널과 데이터 채널

FTP(file transfer protocol)는 RFC 959에 명시되어 있으며, NAT와 상태 기반 방화벽보다 먼저 등장했습니다. 세션은 TCP 포트 21번에 하나의 제어 연결을 열고 세션 전체 기간 동안 이를 유지합니다. 명령어는 일반 텍스트로 전송됩니다. 응답은 세 자리 코드와 텍스트 한 줄로 돌아옵니다. 해당 연결은 파일 콘텐츠를 전송하지 않습니다.

모든 데이터는 각기 별도의 TCP 연결을 사용합니다. 디렉터리 목록 확인(LIST)에 하나, 다운로드(RETR)마다 하나, 업로드(STOR)마다 하나씩 연결이 생성됩니다. 연결은 생성되고, 한 번 사용된 뒤 종료됩니다. 인증은 전적으로 제어 채널에서 이루어지므로, 데이터 경로에 문제가 생기면 항상 동일한 현상이 나타납니다. 즉, 로그인은 성공하지만 이후 응답이 없는 상태가 됩니다. 클라이언트가 230 응답을 출력한 뒤 목록 확인 단계에서 멈춘다면, 이는 자격 증명 문제가 아니라 데이터 채널의 문제입니다.

액티브 모드: 서버가 클라이언트에 역으로 연결

액티브 모드에서는 클라이언트가 포트를 선택하여 대기한 뒤, 서버에 접속할 위치를 알립니다.

PORT 192,168,1,50,195,80

앞의 숫자 4개는 클라이언트의 IP 주소입니다. 뒤의 숫자 2개는 2바이트로 인코딩된 포트 번호로, 195 * 256 + 80 = 50000이 됩니다. 이후 서버는 자신의 20번 포트에서 클라이언트의 50000번 포트로 데이터 연결을 생성합니다.

이 연결은 클라이언트 입장에서 외부에서 들어오는 원치 않는 연결이므로, 클라이언트 방화벽이 이를 차단합니다. 클라이언트가 가정용 공유기 뒤에 있다면 PORT 명령에 포함된 주소는 서버가 전혀 접근할 수 없는 사설 IP가 됩니다. FTP가 제대로 작동하지 않는다는 악명을 얻게 된 원인이 바로 이 액티브 모드입니다.

패시브 모드: 클라이언트가 두 연결을 모두 여는 방식

패시브 모드는 데이터 연결의 방향을 반대로 바꿉니다. 클라이언트가 PASV을 보내면 서버는 자신의 주소와 포트를 응답으로 전달합니다:

227 Entering Passive Mode (203,0,113,10,195,80)

인코딩 방식은 동일하므로, 클라이언트는 203.0.113.10의 50000번 포트로 연결합니다. 이제 클라이언트가 두 연결을 모두 시작하므로 패시브 모드는 클라이언트 측 NAT 환경에서도 정상적으로 동작하며, 현재 사용되는 모든 클라이언트가 이 방식을 우선적으로 요청합니다.

문제는 사라진 것이 아니라 위치가 바뀌었을 뿐입니다. 이제 예기치 않은 인바운드 연결이 서버 측의 높은 포트로 들어오게 되며, 이 포트는 전송마다 계속 바뀝니다. 해당 방화벽은 서버 관리자의 책임이므로, 이제 이 문제는 서버 관리자의 몫이 됩니다.

EPSV(확장 패시브 모드, RFC 2428)은 동일한 개념을 더 깔끔한 응답 형식으로 처리합니다:

229 Entering Extended Passive Mode (|||50000|)

응답에 주소 정보가 포함되지 않습니다. 클라이언트는 제어 연결에 이미 사용 중인 주소를 재사용하며, 이 덕분에 IPv6 환경에서도 동작하고 NAT 관련 버그 유형 하나가 완전히 제거됩니다. curl 매뉴얼에 따르면 curl은 일반적으로 PASV보다 EPSV를 먼저 시도합니다. 포트는 여전히 런타임에 결정되므로 EPSV을 사용하더라도 방화벽 규칙 설정에는 변화가 없습니다.

일반적인 방화벽 규칙으로 데이터 채널을 허용할 수 없는 이유

규칙을 작성하는 시점에는 포트 번호가 아직 존재하지 않기 때문입니다. 서버는 전송할 때마다 포트를 선택합니다. 기본 설정 상태에서 vsftpd는 pasv_min_port와 pasv_max_port을 0로 문서화하고 있는데, 이는 "아무 포트나 사용"한다는 의미이므로 데이터 연결은 1023 이상의 모든 포트로 들어올 수 있습니다. sudo ufw allow 21/tcp는 제어 채널만 허용하며 다른 것은 아무것도 허용하지 않는데, 바로 이 설정이 로그인은 성공하지만 목록 조회는 실패하게 만드는 원인입니다. 하나의 고정 포트에서 서비스가 대기한다는 개념이 여전히 모호하다면, Linux에서 포트와 리스닝 소켓이 작동하는 방식이 이에 대한 배경 지식이 됩니다.

상태 저장(stateful) 방화벽은 연결을 추적하며, 커널은 기존 연결에 대한 RELATED으로 새로운 연결을 허용할 수 있습니다. FTP의 경우 제어 스트림을 읽어 227 또는 PORT 라인에서 포트 번호를 추출하는 과정이 필요합니다. 기본적으로는 이러한 작업을 수행하는 기능이 없습니다.

FTP 연결 추적 헬퍼가 더 이상 해결책이 아닌 이유

오래된 가이드들은 커널 모듈 nf_conntrack_ftp를 사용하라고 안내합니다. 이 모듈은 평문 제어 채널을 읽어 통보된 포트를 찾고, 기대(expectation)를 등록하여 특정 포트를 명시하는 규칙 없이도 데이터 연결을 허용합니다. 해당 가이드들이 작성된 이후 네 가지가 변했습니다.

자동 헬퍼 할당 기능은 꺼져 있습니다. 커널 문서는 nf_conntrack_helper sysctl을 "0 - 비활성화(기본값)"로 정의하며 다음과 같이 덧붙입니다: "비활성화된 경우 연결에 헬퍼를 할당하기 위해 iptables 규칙을 설정해야 합니다." 따라서 모듈을 로드하는 것만으로는 아무런 효과가 없습니다.

최신 커널에서는 해당 스위치가 사라졌습니다. sysctl net.netfilter.nf_conntrack_helper을 실행해 보십시오. sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory라는 응답이 돌아온다면 커널에 더 이상 켤 수 있는 자동 헬퍼 할당 기능이 없다는 뜻입니다. 만약 숫자가 반환된다면 스위치가 여전히 존재하며 기본값은 0입니다.

방화벽 프론트엔드 도구들도 이 기능을 더 이상 지원하지 않습니다. Ubuntu 24.04의 man ufw-framework는 /etc/default/ufw 내의 IPT_MODULES 줄에 대해 "이러한 방식으로 연결 추적 모듈(nf_conntrack_*)을 무조건 로드하는 것은 더 이상 권장되지 않는다"고 명시하며, 헬퍼 규칙은 "RULES FILES를 통해 관리해야 한다"고 덧붙입니다. firewalld는 firewalld.conf 내의 AutomaticHelpers에 대해 "더 이상 사용되지 않음. 이 옵션은 무시되며 더 이상 사용되지 않는다"고 기록합니다. 이제 헬퍼를 연결하려면 CT 타겟을 사용하는 명시적 규칙을 직접 작성해야 하는데, 이는 아래의 해결책보다 작업량이 많을 뿐만 아니라 TLS를 활성화하는 순간 작동을 멈춥니다. Ubuntu의 iptables 및 nftables에서 해당 규칙들이 실제로 어디에 위치하는지 확인할 수 있습니다.

TLS는 이 논쟁을 종결시킵니다. 헬퍼는 제어 채널을 텍스트로 읽어 들여 작동합니다. 채널을 암호화하면 헬퍼는 암호문만 보게 되므로 포트를 찾을 수 없습니다. 이에 대한 해결책은 없으며, 있어서도 안 됩니다. 제어 채널을 읽을 수 있는 중간 박스(middlebox)는 곧 사용자의 비밀번호를 읽을 수 있는 중간 박스이기 때문입니다.

서버에서 수동 포트 범위 선언하기

모든 FTP 서버는 사용자가 지정한 범위 내에서 수동 포트를 선택하도록 설정할 수 있습니다. 옵션 명칭은 서버마다 다르므로 실제 운영 중인 서버의 문서를 확인하십시오.

vsftpd의 경우 /etc/vsftpd.conf에서 설정합니다:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

pasv_enable은 이미 YES를 기본값으로 사용합니다. 두 포트 옵션은 기본적으로 0으로 설정되어 있으며, 이는 앞서 설명한 "모든 포트 사용" 동작을 의미합니다. sudo systemctl restart vsftpd로 설정을 적용한 뒤, systemctl status vsftpd를 사용하여 서비스가 정상적으로 재시작되었는지 확인하십시오. vsftpd는 구문 분석이 불가능한 설정 줄이 있으면 이를 무시하지 않고 시작을 거부합니다. 따라서 재시작에 실패하면 journalctl -u vsftpd -n 20을 읽어 방금 입력한 옵션이 포함된 500 OOPS: 줄을 확인하십시오.

ProFTPD의 경우 proftpd.conf에서 설정합니다:

PassivePorts 30000 30099

ProFTPD는 이와 관련하여 기본값을 명시하지 않습니다. 지시어가 없으면 커널이 포트를 선택합니다. 또한 문서에 따르면 범위 내의 포트가 모두 사용 중일 경우 서버는 커널이 할당한 포트로 대체하고 관련 메시지를 로그에 남깁니다. 따라서 범위가 너무 작으면 깔끔하게 실패하는 대신 간헐적으로 오류가 발생하며, 이는 진단하기가 훨씬 어렵습니다. 1024 이상의 비특권 포트를 사용하십시오.

Pure-FTPd는 -p first:last 플래그를 사용합니다. man pure-ftpd에는 이를 "수동 모드 다운로드 시 first에서 last까지의 포트 범위만 사용"하는 기능으로 설명하며, 이 설정은 "pure-ftpd를 패킷 필터와 더 호환되게 만든다"고 명시되어 있습니다. 패키지 빌드 버전은 보통 이 플래그를 설정 파일 내에 포함하므로, 추측하기보다는 배포판의 자체 문서를 확인하여 파일 이름을 찾으십시오.

얼마나 많은 포트가 필요할까요? 동시에 진행되는 데이터 연결당 하나가 필요합니다. 닫힌 TCP 포트는 재사용되기 전까지 TIME_WAIT 상태로 수 분간 머무르므로, 예상되는 최대 동시 접속 수의 몇 배를 할당하십시오. 사용자가 적다면 100개 정도의 포트로 충분하지만, 트래픽이 많은 공개 서버라면 훨씬 더 많은 포트가 필요합니다.

범위는 어디에 위치해야 할까요? 먼저 sysctl net.ipv4.ip_local_port_range를 실행하십시오. 기본 Ubuntu 환경에서는 32768 60999이 출력되는데, 이는 커널이 아웃바운드 연결을 위해 할당하는 포트 범위입니다. 이 범위 내에 수동 포트 범위를 설정하면 이미 포트를 점유 중인 아웃바운드 연결과 충돌할 수 있으므로, 해당 범위보다 낮은 포트를 사용하십시오. 기본 환경에서는 30000에서 30099 사이가 안전합니다. 해당 숫자를 무조건 신뢰하지 말고 반드시 자신의 서버에서 직접 확인하십시오.

방화벽에서 동일한 포트 범위 개방

ufw는 콜론을 사용하여 범위를 표기하며, 매뉴얼에 따르면 범위나 목록을 사용하여 여러 포트를 지정할 때는 반드시 프로토콜을 명시해야 합니다.

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

ufw status verbose을 실행하면 이제 두 항목이 모두 표시됩니다. /tcp 없이 동일한 명령을 실행하면 ufw가 프로토콜을 추측하지 않으므로 tcp 또는 udp를 지정하라는 오류와 함께 거부됩니다. VPS에서의 ufw 규칙 문법에서 나머지 내용을 확인할 수 있습니다.

firewalld는 하이픈을 사용하여 범위를 표기하며, 적용을 위해 reload가 필요합니다.

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

--add-service=ftp은 21/tcp를 개방하고 기본 서비스 정의에 명시된 ftp 헬퍼를 요청합니다. 이 명령만으로는 패시브 포트 범위를 개방하지 않으므로, 이전과 동일한 상태가 유지됩니다. VPS에서의 firewalld 영역 및 서비스에서 더 자세한 내용을 다룹니다.

순수 nftables를 사용하는 경우, input 체인 내부에 다음을 추가합니다.

tcp dport { 21, 30000-30099 } accept

기억해야 할 방화벽이 하나 더 있습니다. 대부분의 호스팅 제공업체는 운영체제 외부의 제어판에서 네트워크 방화벽을 운영합니다. 서버 내부의 규칙이 올바른데도 패킷이 도달하지 않는다면, 해당 제어판에서도 동일한 포트 범위를 개방하십시오.

NAT 환경에서 서버에 공인 IP 주소 알리기

서버에서 ip -4 addr show를 실행하십시오. 인터페이스에 할당된 주소가 클라이언트가 접속하는 주소와 같다면 이 섹션은 건너뛰어도 됩니다. 인터페이스가 사설 주소(10.x, 172.16~172.31.x, 192.168.x)를 가지고 있고 플랫폼이 이를 공인 주소로 매핑하는 경우, 서버는 자신의 공인 주소를 알지 못합니다. vsftpd는 pasv_address의 기본값을 "수신된 연결 소켓에서 주소를 가져옴"으로 정의하므로, 227 응답에는 사설 주소가 포함되며 클라이언트는 도달할 수 없는 곳으로 안내됩니다.

FileZilla는 이 문제를 정확하게 명시합니다:

Server sent passive reply with unroutable address. Using server address instead.

FileZilla는 이를 스스로 수정하여 작업을 계속합니다. 하지만 다른 많은 클라이언트는 그렇지 않습니다. 이들은 10.0.0.5에 연결을 시도하다가 응답 없이 멈춥니다.

curl 또한 이 문제를 숨기는데, curl을 사용하여 테스트할 경우 문제가 될 수 있습니다. 매뉴얼에 따르면 --ftp-skip-pasv-ip은 "기본적으로 활성화됨(7.74.0 버전에서 추가됨)"이므로, curl은 227 응답에 포함된 주소를 무시하고 제어 연결의 주소를 재사용합니다. curl로 작동하는 전송이라도 이 이유 때문에 그래픽 클라이언트에서는 실패할 수 있습니다.

주소를 명시적으로 설정하십시오. vsftpd는 pasv_address=203.0.113.10를 사용하며, 호스트 이름을 입력하려면 pasv_addr_resolve=YES(기본값 NO)을 함께 사용합니다. ProFTPD는 MasqueradeAddress을 사용하며, 여기에는 주소, DNS 이름 또는 인터페이스 이름을 입력할 수 있습니다. Pure-FTPd는 "서버가 매스커레이딩(NAT) 박스 뒤에 있는" 경우를 위해 문서화된 -P를 사용합니다. EPSV은 응답에 주소 필드가 없으므로 이 문제를 완전히 피할 수 있지만, 클라이언트가 어떤 명령을 보낼지 결정하므로 이를 항상 신뢰할 수는 없습니다.

TLS 변경 사항

FTPS는 TLS(Transport Layer Security)를 사용하는 FTP입니다. 클라이언트는 평소처럼 21번 포트에 연결한 뒤, 제어 채널을 보호하기 위해 AUTH TLS을 전송하고, 데이터 채널까지 암호화하기 위해 PROT P를 전송합니다. 일반 FTP는 비밀번호를 평문으로 전송하므로, FTP를 반드시 사용해야 한다면 FTPS를 운영하십시오. vsftpd는 기본적으로 ssl_enable이 NO로 설정되어 배포됩니다.

이로 인해 두 가지 결과가 발생합니다. 첫째, 연결 추적(connection tracking) 헬퍼가 작동하지 않는데, 이는 앞서 언급한 내용을 반대 측면에서 본 것입니다. 둘째, sudo tcpdump -nAi any 'tcp port 21'로는 더 이상 227 응답을 확인할 수 없습니다. 따라서 서버가 어떤 주소와 포트를 알렸는지 확인해야 할 때는 네트워크 패킷을 캡처하는 대신 서버의 자체 로그를 읽어야 합니다.

외부에서 변경 사항 테스트하기

다른 머신에서 다음 명령을 실행하십시오. 서버 자체에서 테스트하면 해결하려는 방화벽을 거치지 않게 됩니다.

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

ss 명령은 FTP 데몬이 21번 포트에서 대기 중임을 보여주어야 합니다. 서버가 유휴 상태일 때는 패시브 포트 범위에서 대기 중인 프로세스가 없습니다. 해당 소켓은 데이터 전송을 위해 생성된 후 전송이 끝나면 닫히기 때문입니다.

--disable-epsv 명령은 curl이 PASV 경로를 사용하도록 강제하며, 이 경로가 주소 문제를 노출합니다. 추적 결과에는 서버의 응답과 curl이 연결을 시도한 주소 및 포트가 출력됩니다.

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004로, 선언된 범위 내에 있습니다. 해당 줄에 사설 주소가 표시된다면 pasv_address 설정이 누락된 것입니다. 설정한 범위 밖의 포트가 표시된다면 서버가 설정 변경 사항을 반영하지 않은 것이므로, 실행 중인 서비스가 참조하는 파일을 올바르게 수정했는지 확인하십시오.

nc 명령은 방화벽 문제를 스스로 해결해 줍니다. 즉시 Connection refused 응답이 온다면 패킷이 서버에 도달했으나 대기 중인 서비스가 없음을 의미하며, 이는 유휴 패시브 포트에서 정상적인 결과입니다. 즉, 규칙이 올바르게 작동하고 있습니다. nc 타임아웃이 발생할 때까지 응답이 없다면 패킷이 어딘가에서 조용히 폐기된 것입니다. 이는 서버 자체의 방화벽이거나 제공업체 패널의 방화벽 때문입니다. 이러한 차이는 SSH의 거부됨(refused)과 시간 초과(timed out)에서 설명한 내용과 동일하며, 모든 포트에 적용됩니다.

아직도 FTP를 사용해야 합니까?

새로운 작업에는 사용하지 마십시오. SFTP(SSH file transfer protocol)는 포트 22번의 단일 SSH 연결 내에서 작동합니다. OpenSSH가 이미 기능을 제공하므로 별도의 두 번째 채널, 수동(passive) 포트 범위, NAT 설정, 추가 데몬 보안 관리가 필요 없습니다. sftp user@example.com는 파일 전송 서비스를 전혀 구성하지 않은 서버에서도 작동합니다. 사용자에게 파일 전송 권한만 부여하려면 sshd_config와 함께 ForceCommand internal-sftp 및 ChrootDirectory을 사용하십시오. 해당 디렉터리는 root가 소유해야 하며 사용자가 쓰기 권한을 가져서는 안 됩니다. 그렇지 않으면 sshd가 세션을 거부하고 bad ownership or modes for chroot directory 로그를 남깁니다.

FTP는 상대방의 환경을 변경할 수 없는 경우에만 사용합니다. 스캐너나 복합기 같은 장비는 FTP만 지원하는 펌웨어를 탑재하고 있습니다. 실험실이나 산업용 장비는 재인증이 불가능한 고정된 이미지를 사용하는 경우가 많습니다. 비즈니스 파트너가 FTPS 드롭박스를 운영하며 특정 공급업체를 위해 프로토콜을 추가하지 않는 경우도 있습니다. 이러한 경우에는 수동(passive) 포트 범위와 그에 맞는 방화벽 규칙을 설정하는 것이 전부이며, 일반 FTP 대신 FTPS를 사용해야 합니다. 두 개의 채널을 사용하는 설계는 1985년에 결정된 것으로, 현재의 환경을 전혀 예상하지 못한 방식입니다. 이에 관한 자세한 내용은 파일 전송 프로토콜의 역사에서 확인할 수 있습니다.

FAQ

FTP 로그인은 성공하는데 디렉터리 목록을 불러올 때 멈추는 이유는 무엇입니까?

로그인은 방화벽이 허용하는 21번 포트의 제어 연결만 사용합니다. 디렉터리 목록을 불러오려면 다른 포트에서 두 번째 TCP 연결이 필요한데, 이 연결이 차단된 상태입니다. FTP 서버에 패시브 포트 범위를 지정하고 방화벽에서도 동일한 범위를 개방하면 목록이 정상적으로 표시됩니다. 목록 불러오기가 멈추는 현상은 데이터 채널 문제이며, 비밀번호와는 무관합니다.

FTP 패시브 모드를 위해 어떤 포트를 열어야 합니까?

제어 채널을 위한 21번 포트와 패시브 데이터 연결을 위해 설정한 포트 범위를 열어야 합니다. 표준 범위는 없으며 사용자가 직접 선택합니다. 30000에서 30099와 같은 범위를 사용하면 됩니다. 동시 전송 최대치를 고려하여 범위를 정하고, sysctl net.ipv4.ip_local_port_range 명령으로 확인할 수 있는 커널의 아웃바운드 포트 범위와 겹치지 않게 설정하십시오. 클라우드 제공업체의 제어판에서 네트워크 방화벽을 운영 중이라면 해당 방화벽에서도 동일한 범위를 개방해야 합니다.

여전히 nf_conntrack_ftp가 필요합니까?

아니요, 최신 커널에서는 이를 신뢰할 수 없습니다. 자동 헬퍼 할당은 기본적으로 비활성화되어 있으며, 최근 커널에서는 net.netfilter.nf_conntrack_helper 스위치가 제거되어 sysctl 명령을 실행하면 파일이 존재하지 않는다는 오류가 발생합니다. ufw 매뉴얼은 해당 모듈을 무조건 로드하는 방식을 권장하지 않으며, firewalld는 AutomaticHelpers 설정을 완전히 무시합니다. 또한 헬퍼는 제어 채널을 평문으로 읽어야 하므로 FTPS를 활성화하는 순간 작동이 중단됩니다. 대신 패시브 포트 범위를 명시적으로 설정하십시오.

FTP 클라이언트에서 패시브 응답 주소를 라우팅할 수 없다는 오류가 발생하는 이유는 무엇입니까?

서버가 PASV 응답을 보낼 때 자신의 인터페이스에 할당된 사설 IP 주소를 포함했기 때문입니다. 이는 플랫폼이 공인 IP를 사설 IP로 매핑할 때 발생합니다. 공인 IP를 명시적으로 설정하십시오. vsftpd는 pasv_address, ProFTPD는 MasqueradeAddress, Pure-FTPd는 -P 설정을 사용합니다. FileZilla는 이미 연결된 주소를 재사용하여 "Using server address instead"라는 로그를 남기며 우회하므로, 일부 클라이언트는 설정 오류에도 정상 작동하지만 다른 클라이언트는 멈추게 됩니다.

FTPS와 SFTP 중 무엇을 사용해야 합니까?

양쪽 끝을 모두 제어할 수 있는 환경이라면 SFTP를 사용하십시오. 22번 포트의 SSH 연결 하나만 사용하므로 별도의 데이터 채널을 열 필요가 없으며 이미 실행 중인 경우가 많습니다. FTPS는 TLS 기반의 FTP이므로 두 개의 채널을 사용하는 구조와 그에 따른 모든 방화벽 문제를 그대로 안고 있습니다. 상대방이 다른 프로토콜을 지원하지 않을 때만 FTPS를 선택하십시오. 인터넷을 통해 평문 FTP를 사용하는 것은 비밀번호가 그대로 노출되므로 절대 금지해야 합니다.