VPS에서 obfs4 Tor 브리지 구축 및 설정 방법

Tor 브리지의 정의와 존재 이유

Tor 브리지란 공개 릴레이 목록에 주소가 게시되지 않는 Tor 네트워크의 진입점을 의미합니다. consensus라고 불리는 이 목록은 누구나 다운로드할 수 있는 서명된 문서이며, 검열 기관 또한 이를 다운로드합니다. consensus를 확보한 뒤 그 안에 포함된 모든 주소를 경계망에서 차단하는 것만으로도 Tor 접속을 막는 데는 반나절이면 충분합니다. 브리지는 바로 이 공개된 목록이 가진 취약점을 보완하기 위해 존재합니다. 브리지 주소는 한 번에 소량씩만 배포되므로, 단일 요청으로 전체 목록을 탈취할 수 없습니다.

목록에 없는 주소라는 점만으로는 충분하지 않습니다. 주소가 아닌 콘텐츠를 기반으로 트래픽을 분류하는 심층 패킷 분석(DPI, Deep Packet Inspection) 기술은 TLS(Transport Layer Security) 핸드셰이크의 형태만으로도 Tor 연결임을 식별할 수 있습니다. 목록이 없는 검열 기관이라도 "이것은 Tor처럼 보인다"고 판단하여 연결을 끊을 수 있습니다. 플러그러블 트랜스포트(pluggable transport)는 이러한 신호를 제거합니다. 클라이언트 측에서 Tor 스트림을 다른 형태로 감싸고, 브리지에서 이를 다시 풀어내는 방식을 사용합니다.

obfs4는 대부분의 브리지에서 사용하는 트랜스포트입니다. 이 기술은 스트림을 헤더나 고정된 핸드셰이크가 없는 바이트 형태로 변환하므로 DPI가 일치시킬 패턴을 찾을 수 없게 합니다. 또한 클라이언트를 인증하는 기능도 포함되어 있습니다. 브리지 라인 내의 cert= 값은 클라이언트가 브리지로부터 응답을 받기 위해 반드시 증명해야 하는 키입니다. 이는 능동적 탐지(active probing)를 무력화합니다. 검열 기관이 해당 주소에 접속하여 Tor 프로토콜을 사용하는지 확인하려 해도, 브리지는 아무런 응답을 하지 않으므로 정보를 얻을 수 없습니다.

어떤 플러그형 전송(pluggable transport)을 실행해야 합니까?

• obfs4는 하나의 VPS와 두 개의 TCP 포트가 필요하며 도메인 이름은 필요하지 않습니다. 이것은 실행할 수 있는 가장 간편하고 유용한 도구이며, 이 가이드의 주제이기도 합니다.
• WebTunnel은 일반적인 HTTPS 트래픽 내부에 연결을 숨겨 실제 웹사이트처럼 보이게 합니다. Tor Project에서 명시하는 요구 사항은 고정 IPv4 주소, 직접 제어하는 도메인, NGINX나 Apache와 같은 정상 작동하는 웹 서버, 유효한 TLS 인증서, 그리고 최소 1 GB의 RAM(4 GB 권장)입니다. 웹 브라우징 외의 활동을 거의 허용하지 않는 국가에서도 HTTPS는 허용하므로, 무작위로 보이는 트래픽 자체가 의심을 사는 네트워크 환경에 적합합니다.
• Snowflake는 다른 방식의 기여입니다. 자원봉사자가 단기 WebRTC 프록시를 실행하므로 진입점이 계속 바뀌며, 검열자가 차단할 수 있는 고정된 주소가 존재하지 않습니다. 사용자가 직접 브리지를 운영하는 방식이 아닙니다. 프록시를 실행하는 것이며 고정 주소도 필요하지 않습니다.

obfs4로 시작하십시오. 나중에 다른 주소로 WebTunnel 브리지를 추가할 수 있습니다. 하나의 IP에서 두 가지를 모두 실행하면 해당 주소가 차단될 경우 두 서비스가 모두 중단됩니다.

브리지 운영 비용은 얼마입니까?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

2026년 8월 기준으로 Tor Project는 브리지에 최소 1 Mbit/s의 업로드 및 다운로드 대역폭을 요구합니다. 가드(guard) 또는 중간(middle) 릴레이의 경우 10 Mbit/s를 요구하며, 16 Mbit/s를 권장합니다. 이는 게시된 요구 사항일 뿐 실제 측정값은 아닙니다. 새로운 브리지는 보통 수주 동안 최소 요구치보다 훨씬 낮은 대역폭을 사용합니다. 동일한 요구 사항 페이지에서 릴레이는 월간 최소 100 GByte의 아웃바운드 트래픽을 처리할 것을 요구하는데, 이는 가장 저렴한 플랜으로도 충분히 충족할 수 있습니다. 따라서 더 큰 사양을 선택하기 전에 소규모 VPS의 실제 월간 비용을 먼저 확인하십시오.

악용 사례(abuse)가 발생할 가능성은 작으며, 많은 사람이 이 부분을 오해합니다. 브리지는 첫 번째 홉(hop)입니다. 서버를 떠나는 트래픽은 다른 Tor 릴레이로 전달될 뿐, 사용자가 선택한 웹사이트로 직접 향하지 않습니다. 귀하의 IP 주소가 타인의 웹 로그에 요청의 근원지로 기록되는 일은 없으므로, 엑시트 릴레이 운영자가 받는 항의 메일이 귀하에게 전달되지 않습니다. 다만 일부 호스팅 업체는 모든 Tor 서비스를 특별한 경우로 취급하므로, 이용 중인 업체의 서비스 이용 약관(AUP)을 확인하는 것이 좋습니다. 브리지와 onion 서비스는 이런 측면에서 정반대입니다. 브리지는 주소가 도달 가능하고 결국 배포되어야 유용하지만, 동일한 유형의 VPS에서 운영하는 v3 onion 서비스는 공용 IP가 노출되지 않아야만 유용합니다.

절대 하지 말아야 할 행동은 기존의 공용 릴레이를 동일한 주소에서 브리지로 전환하는 것입니다. 이 경우 Tor Project는 "IP 주소, 이름, 핑거프린트"를 모두 변경할 것을 권장합니다. 이전 주소는 이미 검열 기관이 다운로드하는 컨센서스(consensus)에 포함되어 있기 때문입니다. 지난주까지 공용 릴레이였던 브리지는 이미 차단 목록에 올라가 있는 브리지와 다름없습니다.

속도보다 가동 시간(uptime)이 더 중요합니다. 릴레이 요구 사항에 따르면 "릴레이가 하루 2시간 이상 작동하지 않으면 유용성이 제한된다"고 명시되어 있으며, 브리지는 각 클라이언트가 하나의 주소만 사용하고 대체 수단이 없기 때문에 릴레이보다 상황이 더 나쁩니다. 재시작 시 연결된 모든 사용자의 접속이 끊깁니다. Uptime Kuma에서 TCP 포트 확인을 설정하여 obfs4 포트가 응답을 멈추는 즉시 알 수 있도록 하십시오.

Tor Project 저장소에서 Tor 설치하기

배포판 패키지는 버전이 뒤처지는 경우가 많습니다. 브리지(bridge)는 보안 소프트웨어이므로 항상 최신 상태를 유지해야 합니다. 먼저 프로젝트 공식 저장소를 추가하십시오.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

이제 소스 파일을 작성하십시오. Suites: 줄에는 현재 시스템의 릴리스 코드네임이 들어가야 하므로, 기억에 의존하지 말고 시스템에서 직접 읽어와야 합니다.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

apt update 명령 실행 시 해당 코드네임에 대한 Release 파일을 찾을 수 없다는 오류가 발생한다면, Tor Project에서 해당 릴리스를 지원하지 않는 것입니다. 이 경우 /etc/apt/sources.list.d/tor.sources 파일을 삭제하고 sudo apt update을 다시 실행한 뒤, 배포판에서 제공하는 tor 패키지를 설치하십시오. 아래의 모든 과정은 동일합니다.

obfs4proxy 패키지는 Debian 및 Ubuntu 자체 저장소에서 제공됩니다(2026년 8월 기준, Debian 13에서는 버전 0.0.14). 바이너리가 설치된 위치를 확인하십시오. 해당 경로는 설정 파일에 입력해야 합니다.

command -v obfs4proxy || command -v lyrebird

업스트림에서 프로젝트 명칭을 lyrebird로 변경했으므로, 최신 패키지에서는 /usr/bin/lyrebird이 설치될 수 있습니다. 해당 명령어가 출력하는 경로를 사용하십시오.

/etc/tor/torrc에서 브리지 설정하기

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

이 줄들은 각각 실패 요인을 포함하고 있으므로 하나씩 차례대로 다루어야 합니다.

BridgeRelay 1는 tor가 자신의 디스크립터를 공개 합의(public consensus)가 아닌 브리지 권한(bridge authority)으로 전송하도록 지시합니다. 이 한 줄이 릴레이를 비공개 상태로 만드는 핵심입니다.

ORPort은 실제 Tor 포트입니다. tor는 이 포트를 테스트하며 테스트를 통과하기 전까지는 디스크립터를 게시하지 않으므로, 인터넷에서 접근 가능해야 합니다.

ServerTransportPlugin는 tor에 실행 명령을 내립니다. tor는 obfs4proxy를 자식 프로세스로 시작하고 파이프를 통해 통신하므로, obfs4proxy는 별도의 서비스 유닛을 갖지 않으며 systemctl status에도 나타나지 않습니다.

ServerTransportListenAddr은 obfs4proxy가 수신 대기할 포트를 고정합니다. 이 줄을 생략하면 obfs4proxy는 시작할 때마다 사용 가능한 포트를 무작위로 선택하며, 재시작할 때마다 포트가 바뀝니다. 결과적으로 이미 배포한 모든 브리지 라인이 아무것도 수신하지 않는 포트를 가리키게 됩니다. 해당 클라이언트들은 연결 거부 상태가 되어 접속 시도를 중단합니다.

ExtORPort auto은 확장 ORPort를 엽니다. 이는 obfs4proxy가 완료된 연결을 클라이언트 주소와 함께 tor로 전달하기 위해 사용하는 루프백 채널입니다. Tor 프로젝트의 설정 가이드에는 모든 브리지에 이 설정이 포함되어 있는데, 이 설정이 없으면 전송 계층이 tor에 해당 주소를 보고할 수 없기 때문입니다.

ContactInfo과 Nickname는 모두 공개 정보입니다. 브리지에 문제가 생겼을 때 Tor 프로젝트가 연락할 수 있도록 자주 확인하는 이메일 주소를 사용하고, 신원을 드러내고 싶지 않다면 본인을 식별할 수 없는 닉네임을 선택하십시오.

BridgeDistribution은 어떤 배포자가 사용자에게 귀하의 주소를 제공할지 결정합니다. 허용되는 값은 https, email, telegram, settings, none, any입니다. 첫 브리지라면 any을 사용하여 시스템이 결정하도록 하십시오. 직접 배포하는 개인용 브리지라면 none을 사용하여 주소가 공개 배포망에 노출되지 않도록 하십시오.

포트 선택이 중요한 이유

두 포트 모두에 9001을 사용하는 것은 피해야 합니다. Tor Project에서 직접 권고하는 사항이며, 9001은 전통적인 ORPort로 사용되어 검열 기관이 인터넷상에서 해당 포트를 스캔하기 때문입니다. tor와 obfs4proxy는 각각 별도의 리스너를 바인딩하므로, 두 포트는 서로 달라야 합니다.

가장 강력한 obfs4 포트는 443입니다. 아웃바운드 443은 거의 모든 제한된 네트워크에서 열려 있으며, 이 포트로 연결된 장기 세션은 일반적인 웹 세션처럼 보입니다. 1024 미만의 포트를 바인딩하려면 추가 단계가 필요합니다. obfs4proxy는 root 권한으로 실행되지 않기 때문입니다.

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

열리는 각 편집기에 다음 두 줄을 추가하십시오.

[Service]
NoNewPrivileges=no

기능(capability) 설정만으로는 충분하지 않습니다. systemd의 NoNewPrivileges는 프로세스가 부모 프로세스가 가지지 않은 권한을 획득하지 못하도록 차단하며, 파일 기능(file capability)이 바로 그러한 권한에 해당하므로 해당 설정이 켜져 있는 동안 obfs4proxy는 443 포트 바인딩에 실패합니다.

이 단계를 건너뛰고 싶다면 눈에 띄지 않는 높은 번호의 포트를 선택하고 기록해 두십시오. 무엇을 선택하든 나중에 obfs4 포트를 변경해서는 안 됩니다. 브리지 라인(bridge line)은 주소, 포트, 지문(fingerprint), 인증서를 하나로 묶어 고정하므로, 포트를 변경하는 순간 사용자의 브라우저에 저장된 모든 복사본은 작동하지 않게 됩니다.

양쪽 방화벽의 포트 개방

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

두 포트 모두 개방되어야 합니다. 대부분의 제공업체는 제어판에서 별도의 방화벽을 운영하며, ufw는 이를 인식하지 못합니다. 서버 내부에는 규칙이 존재하지만 제어판에는 없는 경우, 해당 브리지는 연결할 수 없으며 기술자(descriptor)를 게시하지도 못합니다. 이 중 어느 한쪽이라도 생소하다면 새 VPS에 필요한 ufw 규칙과 Linux에서 리스닝 포트의 실제 의미를 참조하십시오. 작업을 진행하는 김에 SSH 키와 강화된 sshd 설정을 사용하여 SSH를 보호하십시오. 비밀번호 기반 SSH를 사용하는 서버에 등록되지 않은 브리지가 있다면, 그 서버는 여전히 비밀번호 기반 SSH에 노출된 상태입니다.

서비스를 시작하고 로그 확인하기

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian과 Ubuntu는 두 개의 unit을 제공합니다. tor.service은 작은 래퍼(wrapper)이며 tor@default.service은 실제 작업을 수행하는 프로세스입니다. 따라서 journalctl -u tor는 거의 비어 있는 것처럼 보이며, 확인해야 할 로그는 tor@default 아래에 있습니다.

정상적으로 작동했음을 나타내는 두 줄의 메시지는 다음과 같습니다.

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

첫 번째 줄은 연결성 테스트를 통과했으며 디스크립터가 브리지 권한(bridge authority)으로 전달되었음을 의미합니다. 만약 이 메시지가 나타나지 않는다면, 인터넷과 서버 사이의 무언가가 ORPort로 향하는 트래픽을 차단하고 있는 것입니다. 두 번째 줄에는 설정한 포트 번호가 표시되어야 합니다. 다른 포트가 표시된다면 tor가 ServerTransportListenAddr를 적용하지 못한 것이며, 일반적인 원인은 전송 이름(transport name)이 일치하지 않기 때문입니다. 두 지시어 모두에서 obfs4로 읽히도록 설정해야 합니다.

두 개의 리스너가 존재하는지 확인하십시오.

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

브리지 라인은 어디에 있습니까?

obfs4proxy는 tor의 데이터 디렉터리에 템플릿을 작성합니다.

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

해당 디렉터리는 tor 사용자의 소유이며 권한은 700으로 설정되어 있으므로, sudo 없이는 Permission denied 오류가 발생합니다. 파일에는 다음과 같은 형태의 라인이 포함되어 있습니다.

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

<IP ADDRESS>을 서버의 공인 IP 주소로, <PORT>를 ORPort가 아닌 obfs4 포트로, <FINGERPRINT>을 tor가 데이터 디렉터리에 기록한 identity fingerprint로 교체하십시오.

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

첫 번째 파일에는 브리지 라인에 필요한 닉네임과 identity fingerprint가 들어 있습니다. 두 번째 파일에는 해시된 fingerprint가 들어 있으며, 이를 Relay Search에 붙여넣어 브리지가 실행 중인지, 대략 몇 명의 클라이언트가 접속 중인지 확인할 수 있습니다. 두 값은 서로 바꿔 사용할 수 없습니다. 해시된 값이 포함된 브리지 라인은 브리지가 제시하는 identity key와 일치하지 않으므로, 클라이언트가 방금 연 연결을 거부하게 됩니다.

브리지는 실제로 어떻게 사용자에게 도달합니까?

브리지 라인을 직접 누구에게 전달할 필요는 없습니다. 기술 정보(descriptor)가 브리지 권한 서버(bridge authority)에 도달하면, 배포 시스템(BridgeDB의 후속인 rdsys)이 해당 브리지를 특정 배포자에게 할당하고, 사용자는 그 배포자에게 브리지를 요청합니다. 2026년 8월 기준으로 경로는 다음과 같습니다.

• bridges.torproject.org/options의 웹 양식: 캡차를 통과하면 브리지 라인을 제공합니다.
• bridges@torproject.org로 보내는 이메일: Gmail 또는 Riseup 주소에서 보내면 브리지 라인으로 회신합니다. 제공자 제한이 있는 이유는 무제한 무료 계정을 허용할 경우 검열자가 모든 브리지를 열거할 수 있기 때문입니다.
• 텔레그램 봇 @GetBridgesBot: /start을 보낸 뒤 /obfs4 또는 /webtunnel을 입력합니다.
• Tor Browser 자체: 설정의 연결 메뉴에서 "브리지 요청"을 선택하면 moat 채널을 통해 브리지를 가져옵니다.

새로운 브리지는 설정 후 약 3시간이 지나면 Relay Search에 나타납니다. 사용자가 연결되기까지는 훨씬 더 오랜 시간이 걸립니다. Tor Project는 "일관된 사용자 집단을 확인하기까지 며칠에서 몇 주가 걸릴 수 있다"고 명시하고 있습니다. 처음 2주 동안 사용자가 없는 것은 오류가 아니라 정상적인 현상입니다.

BridgeDistribution none 설정을 사용하면 이 모든 배포 과정에서 제외됩니다. 이 경우 브리지 라인은 검열자가 감시하지 않는 채널을 통해 직접 필요한 사람에게 전달해야 합니다.

문제가 발생했을 때

로그에 자체 테스트 항목이 없는 경우. ORPort에 도달할 수 없는 상태입니다. 다른 머신에서 nc -vz your.ip 8443를 사용하여 테스트하십시오. 응답이 없으면 패킷이 드롭되는 것이므로 ufw와 제공업체의 제어 패널을 확인하십시오. 연결이 거부되면 tor가 리스닝 중이 아닌 것이므로 ss -lntp을 확인하고 로그에서 설정 오류를 찾으십시오.

등록된 전송 수단에 직접 지정하지 않은 포트가 표시되는 경우. tor가 ServerTransportListenAddr을 무시했습니다. 전송 수단의 이름은 ServerTransportPlugin에 있는 이름과 정확히 일치해야 하며, 둘 다 obfs4여야 합니다.

obfs4proxy가 443 포트에 바인딩되지 않는 경우. getcap /usr/bin/obfs4proxy으로 기능을 확인한 다음, systemctl show tor@default -p NoNewPrivileges을 통해 오버라이드가 유닛에 적용되었는지 확인하십시오. 만약 NoNewPrivileges=yes가 출력된다면, 드롭인 파일이 실행 중이지 않은 유닛에 적용된 것입니다.

/var/lib/tor/pt_state/ 내부에 아무것도 없는 경우. tor가 전송 수단을 시작하지 못한 것이며, 이는 ServerTransportPlugin의 경로가 잘못되었음을 의미합니다. command -v obfs4proxy의 출력 결과와 비교해 보십시오.

변경 후 클라이언트 연결이 중단된 경우. 주소나 obfs4 포트를 변경하면 이미 배포된 모든 브리지 라인이 무효화됩니다. 서버의 공인 IP가 변경되었는지 확인하십시오. 일부 제공업체에서 서버를 재구축할 때 발생할 수 있습니다.

tor가 전혀 시작되지 않는 경우. sudo -u debian-tor tor --verify-config -f /etc/tor/torrc을 실행하십시오. 이 명령은 파일을 파싱하여 문제가 되는 라인을 출력하며, 실행 중인 서비스에는 영향을 주지 않습니다.

FAQ

VPS 제공업체가 Tor 브리지 운영에 대해 문제를 제기할까요?

브리지는 진입점일 뿐이므로 서버에서 나가는 트래픽은 다른 Tor 릴레이로 향하며, 사용자가 선택한 사이트로 직접 연결되지 않습니다. 귀하의 IP 주소는 요청의 근원지로 웹 로그에 기록되지 않으며, 이는 출구 릴레이 운영자가 겪는 불만 사항의 주된 원인입니다. 호스팅 규정은 업체마다 다르며 일부 제공업체는 Tor 서비스를 특별한 사례로 취급하므로, 시작하기 전에 이용 약관을 읽고 확인한 이메일 주소를 ContactInfo에 입력하십시오.

Tor 브리지는 대역폭을 얼마나 사용하나요?

공개된 최소 사양은 업로드 및 다운로드 각각 1 Mbit/s이며, 가드나 중간 릴레이의 경우 10 Mbit/s입니다. 실제 사용량은 0에 가깝게 시작하는데, 이는 브리지가 배포자가 연결해 준 사용자들의 트래픽만 처리하기 때문입니다. 엄격한 상한선을 설정하려면 torrc 파일에서 RelayBandwidthRate 및 RelayBandwidthBurst를 설정하십시오.

왜 새로 만든 브리지에 아무도 연결하지 않나요?

브리지가 Relay Search에 나타나기까지는 약 3시간이 소요되며, Tor Project의 지침에 따르면 일관된 사용자 층이 형성되기까지는 며칠에서 몇 주가 걸립니다. journalctl -u tor@default에서 자체 테스트 라인을 통해 설명자가 게시되었는지 확인하고, Relay Search에서 해시된 핑거프린트를 검색한 뒤 BridgeDistribution이 none로 설정되어 있지 않은지 확인하십시오.

obfs4와 WebTunnel 중 무엇을 운영해야 하나요?

첫 브리지라면 obfs4를 운영하십시오. VPS 한 대, 포트 두 개만 있으면 되며 도메인이나 인증서가 필요 없습니다. WebTunnel은 무작위로 보이는 트래픽조차 차단되는 환경에서 사용하며, 직접 제어하는 도메인, 실제 웹 서버, 유효한 TLS 인증서, 최소 1 GB의 RAM이 필요합니다. 두 가지를 모두 운영한다면 별도의 주소에 배치하십시오. 그렇지 않으면 IP 하나가 차단될 때 브리지 두 개가 동시에 사라지게 됩니다.

나중에 obfs4 포트를 변경하면 어떻게 되나요?

이미 배포된 모든 브리지 라인이 작동을 멈춥니다. 브리지 라인은 주소, 포트, 핑거프린트, 인증서를 하나로 묶어 고정하므로, 이전 라인을 가진 클라이언트는 아무것도 수신하지 않는 포트에 연결을 시도하다가 포기하게 됩니다. 서버의 공인 IP가 변경될 때도 마찬가지입니다. 설정 단계에서 포트를 신중하게 선택하고 이후에는 변경하지 마십시오.