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 surface)은 작으며, 많은 사람이 이 부분을 오해합니다. 브리지는 첫 번째 홉(hop)입니다. 서버를 떠나는 트래픽은 다른 Tor 릴레이로 전달될 뿐, 사용자가 선택한 웹사이트로 직접 연결되지 않습니다. 귀하의 IP 주소는 타인의 웹 로그에 요청의 근원지로 기록되지 않으므로, 엑시트 릴레이 운영자가 받는 불만 메일이 브리지 운영자에게는 오지 않습니다. 다만, 일부 호스팅 업체는 모든 Tor 서비스를 특별한 사례로 취급하므로 제공업체의 이용 약관(AUP)을 미리 확인하십시오.

절대 하지 말아야 할 행동은 기존의 공개 릴레이를 동일한 주소에서 브리지로 전환하는 것입니다. 이 경우 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가 자신의 디스크립터를 공개 컨센서스가 아닌 브리지 권한 서버(bridge authority)로 전송하도록 지시합니다. 이 한 줄이 릴레이를 비공개 상태로 만드는 핵심입니다.

ORPort은 실제 Tor 포트입니다. tor가 이 포트를 테스트하고 테스트를 통과할 때까지 디스크립터 게시를 거부하므로, 인터넷에서 반드시 접근 가능해야 합니다.

ServerTransportPlugin는 tor에게 실행할 명령을 전달합니다. tor는 obfs4proxy를 자식 프로세스로 시작하고 파이프를 통해 통신합니다. 따라서 obfs4proxy는 별도의 서비스 유닛을 가지지 않으며 systemctl status에는 나타나지 않습니다.

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

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

ContactInfo과 Nickname는 모두 공개 정보입니다. Tor Project가 브리지 문제 발생 시 연락할 수 있도록 실제 확인 가능한 이메일 주소를 사용하십시오. 익명을 유지하고 싶다면 본인을 식별할 수 없는 닉네임을 선택하십시오.

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는 프로세스가 부모 프로세스가 가지지 않은 권한을 획득하지 못하도록 차단하며, 파일 capability가 바로 그러한 권한에 해당하므로 해당 설정이 활성화된 상태에서는 obfs4proxy가 443 포트를 바인딩하지 못하고 실패합니다.

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

양쪽 방화벽의 포트 개방

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

두 포트 모두 개방되어야 합니다. 대부분의 제공업체는 제어판에서 별도의 방화벽을 운영하며, ufw는 이를 인식하지 못합니다. 서버 내부에는 규칙이 존재하더라도 제어판에 규칙이 없으면 브리지는 연결할 수 없는 상태가 되며 디스크립터를 게시하지도 못합니다. 이 중 어느 한쪽이라도 생소하다면 새 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는 두 개의 유닛을 제공합니다. 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 자체: 설정(Settings)의 연결(Connection) 메뉴에서 "브리지 요청(Request bridges)"을 선택하면 moat 채널을 통해 브리지를 가져옵니다.

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

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

문제가 발생했을 때

로그에 자가 테스트(self-testing) 줄이 나타나지 않는 경우. ORPort에 접근할 수 없는 상태입니다. 다른 머신에서 nc -vz your.ip 8443를 사용하여 테스트하십시오. 응답이 없으면 패킷이 드롭되고 있는 것이므로 ufw 설정과 제공업체의 관리 패널을 확인하십시오. 연결이 거부되면 tor가 리스닝 상태가 아닌 것이므로 ss -lntp을 확인하고 로그에서 설정 오류를 찾아보십시오.

등록된 전송(transport)에 지정하지 않은 포트가 표시되는 경우. tor가 ServerTransportListenAddr을 무시한 것입니다. 전송 이름은 ServerTransportPlugin에 있는 이름과 정확히 일치해야 하며, 둘 다 obfs4여야 합니다.

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

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

변경 후 클라이언트 연결이 중단된 경우. 주소나 obfs4 포트를 변경하면 이미 배포된 모든 브리지 라인이 무효화됩니다. 서버의 공인 IP가 변경되었는지도 확인하십시오. 일부 제공업체에서는 서버를 재구축할 때 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에서 자기 테스트(self-testing) 라인을 통해 디스크립터가 게시되었는지 확인하고, Relay Search에서 해시된 핑거프린트를 검색한 뒤 BridgeDistribution이 none로 설정되어 있지 않은지 확인하십시오.

obfs4와 WebTunnel 중 무엇을 운영해야 할까요?

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

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

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