가이드

작성자 Matt Connor 2026-08-14

Gluetun 토렌트 포트 포워딩 설정 및 연결 확인 방법

Gluetun 사용 시 다운로드는 되지만 외부 연결이 안 되는 문제를 해결합니다. VPN 재연결 시마다 변경되는 포트 번호를 토렌트 클라이언트에 자동으로 적용하고, 포트 포워딩이 정상적으로 작동하는지 검증하는 구체적인 설정 방법을 안내합니다.

포트 포워딩 없이는 외부 연결이 불가능한 이유

Gluetun 포트 포워딩은 VPN 제공업체에 요청하여 해당 업체의 출구 주소(exit address)에 있는 공인 포트 하나를 사용자의 컨테이너로 매핑합니다. 이것이 외부 피어가 사용자의 토렌트 클라이언트로 연결을 시작할 수 있는 유일한 방법입니다. 이러한 매핑이 없으면 터널은 정상적으로 작동하고 다운로드는 수행되지만, 외부에서 들어오는 연결은 전혀 수신되지 않습니다. 현재 작동 중인 모든 연결은 사용자의 클라이언트가 먼저 시작한 연결뿐입니다.

이 메커니즘은 NAT(Network Address Translation)입니다. 사용자의 컨테이너는 여러 다른 고객과 함께 제공업체의 출구 주소를 공유합니다. 클라이언트가 외부로 연결을 시작하면 제공업체는 해당 흐름을 기록하고 응답을 다시 터널로 보냅니다. 외부의 낯선 피어가 내부로 연결을 시도하면 기록된 흐름과 일치하는 항목이 없으므로, 패킷은 출구 주소에 도달한 뒤 폐기됩니다. 사용자의 클라이언트는 연결 가능한 상태인 모든 피어에 접근할 수 있으므로 다운로드는 완료되며, 이 문제는 겉으로 드러나지 않습니다. 시딩(seeding)을 할 때 문제가 드러나는 이유는 시더(seeder)가 다른 사람들이 연결해 오는 대상이기 때문입니다.

인바운드 포트가 열리면 두 가지가 바뀝니다. 첫째, 스스로 연결을 수락할 수 없는 피어들도 이제 사용자에게 도달할 수 있게 되어 스웜(swarm)에 더 빠르게 참여할 수 있습니다. 둘째, 그러한 피어들에게 데이터를 업로드할 수 있게 됩니다.

대부분의 VPN 제공업체가 포트 포워딩을 제공하지 않는 이유

포트 포워딩은 공유 IP 주소에서 매우 희소한 자원입니다. 제공업체는 하나의 출구 IP에서 하나의 포트 번호를 특정 고객에게 할당해야 하며, 해당 고객이 그 포트로 수행하는 모든 활동에 대해 책임을 져야 합니다. 여러 대형 제공업체가 이러한 이유로 악용 사례 대응이 어렵다는 점을 들어 해당 기능을 제거했습니다. 지원 여부를 단순한 체크박스 항목으로 보지 말고 범주형 질문으로 다루어야 합니다. 현재 사용 중인 요금제와 실제로 선택 가능한 서버에서 포트 포워딩을 제공하는지 직접 문의하십시오.

포트 포워딩이 지원되는 경우에도 포트는 동적으로 할당됩니다. 포트는 계정이 아닌 VPN 세션에 귀속되므로, 재연결할 때마다 번호가 바뀔 수 있습니다. Private Internet Access는 서명된 포트를 발급하며 gluetun이 이를 갱신합니다. 업스트림 문서에 따르면 /gluetun 디렉터리를 바인드 마운트하여 재시작 후에도 상태가 유지되도록 설정하면 60일 동안 동일한 포트를 유지할 수 있습니다. ProtonVPN은 NAT-PMP(NAT Port Mapping Protocol)를 통해 짧은 임대 기간의 무작위 포트를 할당하며, 이를 지속적으로 갱신해야 합니다. 클라이언트에서 포트를 한 번 설정하는 것만으로는 작동이 유지되지 않는 이유가 바로 이것입니다.

gluetun이 포트를 요청할 수 있는 제공업체

2026년 7월 30일에 릴리스된 gluetun v3.41.3 기준으로, 기본 통합 기능은 Private Internet Access, ProtonVPN, Perfect Privacy, PrivateVPN 등 4개 제공업체 이름을 검증합니다. VPN_PORT_FORWARDING=on을 사용하여 활성화하며, 기본값은 off입니다. 이전 가이드에서는 PORT_FORWARDING나 PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING을 사용합니다. 두 이름 모두 이 버전에서 하위 호환성을 위해 여전히 작동하지만, 점차 사용이 중단될 예정입니다.

제공업체의 세부 설정 두 가지가 포트 요청 성공 여부를 결정합니다. ProtonVPN은 유료 플랜이 필요하며 NAT-PMP가 켜져 있어야 합니다. WireGuard 구성을 생성할 때 VPN 옵션에서 NAT-PMP (Port Forwarding)을 활성화하거나, OpenVPN을 사용할 때 사용자 이름 뒤에 +pmp을 추가하십시오. OpenVPN을 사용하는 Private Internet Access에는 PORT_FORWARD_ONLY 설정이 있는데, 이는 포트 포워딩을 지원하는 서버로만 선택 범위를 제한하여 지원하지 않는 서버에 연결되는 것을 방지합니다. WireGuard와 OpenVPN은 포트 요청 방식이 다르므로, 선택하기 전에 해당 제공업체의 페이지를 읽어보십시오.

gluetun이 내장 제공업체 대신 사용자 정의 구성을 실행할 때, VPN_PORT_FORWARDING_PROVIDER은 gluetun이 호출해야 할 API를 지정합니다. Private Internet Access 상위 페이지에서는 이 변수를 VPN_PORT_FORWARDING_USERNAME 및 VPN_PORT_FORWARDING_PASSWORD와 함께 사용하며, 여기에는 포트 요청에 필요한 계정 자격 증명이 포함됩니다.

Docker Compose에서 gluetun 포트 포워딩 활성화하기

이 가이드는 터널이 이미 정상적으로 작동한다고 가정합니다. 만약 작동하지 않는다면, 먼저 gluetun을 통한 Docker 컨테이너 트래픽 라우팅을 수행하여 다운로드가 정상적으로 이루어지는지 확인한 뒤 돌아오십시오.

services:
  gluetun:
    image: qmcgaw/gluetun:v3.41.3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8080:8080/tcp
      - 8000:8000/tcp
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - VPN_PORT_FORWARDING=on
      - TZ=Etc/UTC
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:5.2.3
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      - gluetun
    restart: unless-stopped

이미지 태그를 고정하십시오. qmcgaw/gluetun:latest은 master 브랜치를 따르는데, v4를 위해 포트 포워딩 내부 구조가 변경되고 있으므로 태그를 고정하지 않으면 다음 docker compose pull 시점에 동작이 바뀔 수 있습니다. Compose 보안을 위한 환경 변수 파일을 사용하여 개인 키가 compose 파일에 노출되지 않도록 하십시오.

Gluetun이 포트 포워딩 정보를 기록하는 위치

Gluetun은 세 곳에 포트 번호를 노출하며, 모든 위치에서 동일한 값을 제공합니다.

Gluetun은 포트를 획득할 때마다 로그를 남깁니다. 해당 줄은 port forwarded is 45678로 표시되며, 요청 결과가 없을 때는 no port forwarded으로 표시됩니다.

docker logs gluetun 2>&1 | grep -i "port forwarded"

Gluetun은 VPN_PORT_FORWARDING_STATUS_FILE에 지정된 파일에 포트 번호를 기록하며, 기본값은 /tmp/gluetun/forwarded_port입니다. 이 파일은 줄마다 하나의 포트를 저장하며 0644 모드로 작성되고, 컨테이너의 PUID 및 PGID 소유로 변경됩니다. 포트 포워딩이 중단되면 Gluetun은 파일을 삭제하는 대신 내용을 비우므로, 소비자는 파일이 없는 상태를 마주하는 대신 빈 파일을 읽을 수 있습니다.

docker exec gluetun cat /tmp/gluetun/forwarded_port

Gluetun은 제어 서버를 통해 해당 값을 제공합니다. 제어 서버는 기본적으로 :8000에서 대기하며, HTTP_CONTROL_SERVER_ADDRESS을 통해 설정할 수 있습니다.

curl -s http://127.0.0.1:8000/v1/portforward

{"port":45678,"ports":[45678]}

또한 Gluetun은 VPN 인터페이스의 자체 방화벽에서 해당 포트를 개방하므로, 기본 통합 기능을 사용하는 동안에는 FIREWALL_VPN_INPUT_PORTS가 필요하지 않습니다. 해당 변수는 다른 경우, 즉 Gluetun이 쿼리할 수 없는 제공업체로부터 정적 포트를 별도로 할당받아 수동으로 허용해야 하는 경우에 사용합니다.

이 세 가지 방식 중 하나는 영구적이며 두 가지는 그렇지 않습니다. 업스트림 문서에서는 v4.0.0부터 상태 파일을 더 이상 사용하지 않는 것으로 표시하고 있으며, GET /v1/openvpn/portforwarded는 이미 /v1/portforward을 가리키는 301 Moved Permanently으로 응답하고 있습니다. 새로운 구현 작업 시에는 제어 서버를 읽는 방식을 사용해야 합니다.

재연결 시마다 클라이언트에게 포트를 알려주어야 하는 이유

토렌트 클라이언트는 수신 대기 포트를 자체 설정에 저장하며, 재시작 후에도 해당 번호를 유지합니다. 반면 포트 포워딩은 VPN 세션의 속성입니다. 재연결 후에는 두 번호가 일치하지 않게 되며, 결과적으로 제공자는 아무것도 수신하지 않는 포트를 매핑하고 클라이언트는 아무것도 매핑되지 않은 포트에서 대기하게 됩니다. 재연결은 드문 일이 아닙니다. 컨테이너 재시작, 서버 변경, gluetun의 상태 확인으로 재시작된 끊긴 터널, 또는 갱신되지 못한 임대 등이 그 예입니다. 그 결과 어제까지는 연결 가능했던 설정이 오늘 아무런 로그 오류 없이 조용히 연결 불가능한 상태가 됩니다.

따라서 포트는 gluetun이 이를 획득하는 즉시 적용되어야 합니다. 이를 연결하는 방법에는 두 가지가 있으며, 어떤 프로세스가 작업을 수행하느냐에 따라 차이가 있습니다.

옵션 1: gluetun이 up 명령어로 포트를 전달하는 방식

VPN_PORT_FORWARDING_UP_COMMAND은 포트 포워딩이 활성화될 때 실행되며, VPN_PORT_FORWARDING_DOWN_COMMAND는 비활성화될 때 실행됩니다. Gluetun은 명령어를 실행하기 전에 {{PORT}}(첫 번째 포트), {{PORTS}}(쉼표로 구분된 모든 포트), {{VPN_INTERFACE}}(터널 인터페이스 이름, 기본값은 tun0)를 실제 값으로 치환합니다. 셸 문법을 사용하려면 명시적인 /bin/sh -c 래퍼가 필요합니다. 다음은 qBittorrent를 업스트림으로 사용하는 예시이며, compose 환경 변수 두 줄로 작성되었습니다.

      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":{{PORT}},\"current_network_interface\":\"{{VPN_INTERFACE}}\",\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'

이 호출의 각 필드는 고유한 역할을 합니다. listen_port는 새로운 포트입니다. current_network_interface은 qBittorrent를 터널에 바인딩합니다. random_port을 false로 설정하면 다음 시작 시 qBittorrent가 임의의 포트를 선택하는 것을 방지합니다. upnp을 false로 설정하면 존재하지 않는 라우터를 통해 포트 매핑을 시도하는 것을 방지합니다.

이 방식에는 두 가지 요구 사항이 있습니다. qBittorrent의 웹 UI는 gluetun 컨테이너 내부의 127.0.0.1:8080에서 응답해야 하며, 클라이언트가 gluetun의 네트워크 네임스페이스를 공유하는 경우 이는 자동으로 처리됩니다. 또한 명령어가 자격 증명을 전송하지 않으므로 Bypass authentication for clients on localhost(bypass_local_auth)이 활성화되어 있어야 합니다. down 명령어가 필요한 이유는 qBittorrent가 연결 해제 후 포트를 항상 재설정하지는 않기 때문입니다.

이 명령어는 Alpine 기반으로 빌드되어 wget를 포함하는 gluetun 컨테이너 내부에서 실행됩니다. 해당 이미지에는 curl이 없습니다. 이미지에 존재하지 않는 바이너리를 호출하는 명령어는 포워딩이 활성화될 때마다 실패합니다.

옵션 2: gluetun 외부의 프로세스가 포트를 읽는 방식

다른 패턴은 gluetun 옆에서 작은 프로세스를 실행하여 포트를 가져온 뒤, 클라이언트 자체 API를 통해 클라이언트로 전달하는 방식입니다. 제어 서버에서 포트를 읽어옵니다:

port=$(curl -s http://127.0.0.1:8000/v1/portforward | jq -r .port)

또는 프로세스가 접근할 수 있다면 파일을 읽습니다. /tmp/gluetun/forwarded_port는 gluetun 컨테이너 내부에 위치하므로, 사이드카 컨테이너는 두 컨테이너 모두에 마운트된 공유 볼륨이 /tmp/gluetun에 필요합니다. 혹은 이미 마운트된 볼륨 하위의 경로를 VPN_PORT_FORWARDING_STATUS_FILE으로 지정할 수도 있습니다.

여기서는 인증이 중요합니다. v3.41.3 버전에서 GET /v1/portforward 경로는 auth = "none" 권한을 가진 public이라는 기본 역할에 속해 있으므로, 자격 증명 없이 응답하며 gluetun은 route GET /v1/portforward is unprotected by default, please set up authentication으로 시작하는 경고 로그를 남깁니다. 이후 릴리스에서는 이 경로가 차단될 예정입니다. 지금 /gluetun/auth/config.toml에 바인드 마운트된 파일에 역할을 정의하십시오:

roles = [
  { name = "qbittorrent", routes = ["GET /v1/portforward"], auth = "apikey", apikey = "myapikey" }
]

docker run --rm qmcgaw/gluetun:v3.41.3 genkey로 키를 생성하고 X-API-Key 헤더에 포함하여 전송하십시오. 파일을 마운트하고 싶지 않을 때 HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE는 JSON으로 인코딩된 환경 변수와 동일한 역할을 수행합니다. 역할 정의 없이 8000번 포트를 공개하면 해당 포트에 접근할 수 있는 누구나 VPN 상태를 제어할 수 있게 됩니다. 따라서 호스트 및 다른 컨테이너에서 gluetun에 접근하는 방법을 결정할 때 포트가 노출되는 범위를 신중하게 고려하십시오.

클라이언트가 wget 호출 한 번으로 제어 가능한 API를 제공한다면 up 명령어를 선택하십시오. 이는 이벤트당 정확히 한 번 실행되며 별도의 상주 프로세스가 필요 없기 때문입니다. 클라이언트가 로그인 절차, 설정 파일 재작성, 또는 재시작을 필요로 한다면 외부 프로세스를 선택하십시오. 하나의 gluetun 컨테이너 뒤에 구성된 arr 스택에서는 토렌트 클라이언트만 포트 정보를 필요로 하므로, 보통 작은 폴러(poller) 하나를 사용하는 방식으로 마무리됩니다.

함정: 네임스페이스 공유가 리스닝 포트를 설정하지 않음

이 오류는 가장 많은 시간을 낭비하게 만듭니다. network_mode: "service:gluetun"은 클라이언트를 gluetun의 네트워크 네임스페이스에 배치하므로, 클라이언트는 VPN 주소, 터널 경로, gluetun의 방화벽 규칙을 갖게 됩니다. 하지만 이 중 어느 것도 클라이언트의 리스닝 포트를 설정해주지는 않습니다. Gluetun은 VPN 인터페이스에서 포워딩된 포트를 열고 해당 네임스페이스로 패킷을 전달하지만, 클라이언트가 다른 포트에서 대기 중이라면 커널은 패킷을 전달할 곳을 찾지 못합니다. 아웃바운드 확인은 모두 정상으로 보임에도 연결이 거부되거나 타임아웃이 발생합니다. 포워딩된 포트와 클라이언트의 리스닝 포트는 서로 다른 두 개의 숫자이며, 이 둘을 일치시키는 것이 핵심 작업입니다.

추측하지 말고 두 값을 비교하십시오. 다음 두 명령은 동일한 네임스페이스에서 실행됩니다.

docker exec gluetun cat /tmp/gluetun/forwarded_port
docker exec gluetun wget -qO- http://127.0.0.1:8080/api/v2/app/preferences | grep -o '"listen_port":[0-9]*'

사람들을 잘못된 방향으로 이끄는 설정이 하나 더 있습니다. VPN_PORT_FORWARDING_LISTENING_PORT은 iptables를 사용하여 포워딩된 포트로 들어오는 트래픽을 고정된 로컬 포트로 리다이렉트합니다. 업스트림에서는 토렌트 클라이언트와 함께 이 설정을 사용하지 말라고 권고합니다. 클라이언트가 트래커와 피어에게 자신의 리스닝 포트를 직접 알리기 때문에, 스웜(swarm)이 잘못된 포트 번호를 학습하게 되기 때문입니다.

포트 포워딩 연결 가능 여부 확인 방법

클라이언트의 자체 연결 표시기는 아웃바운드 트래커 연결을 반영하므로, 외부에서 아무것도 접근할 수 없는 상태여도 녹색으로 표시될 수 있습니다. 터널 외부 네트워크에서 직접 제어 가능한 리스너를 사용하여 테스트하십시오. 업스트림에서 이를 위한 작은 도구를 제공합니다. 두 프로세스가 동일한 포트를 바인딩할 수 없으므로 먼저 토렌트 클라이언트를 중지하십시오.

docker stop qbittorrent
docker exec -it gluetun /bin/sh

컨테이너 내부에서 amd64을(를) 본인의 CPU 아키텍처에 맞게, 4567을(를) 포워딩된 포트 번호로 변경하십시오:

wget -qO port-checker https://github.com/qdm12/port-checker/releases/download/v0.4.0/port-checker_0.4.0_linux_amd64
chmod +x port-checker
./port-checker --listening-address=":4567"

이제 gluetun이 사용 중인 외부 주소를 확인하십시오. 응답은 JSON 형식이며 주소는 public_ip 필드에 있습니다.

curl -s http://127.0.0.1:8000/v1/publicip/ip

동일한 VPN을 사용하지 않는 기기에서 http://<that address>:4567을(를) 여십시오. 모바일 데이터를 사용하는 스마트폰도 좋습니다. 브라우저의 IP 주소와 사용자 에이전트가 표시되는 페이지에서 port-checker가 일치하는 요청을 기록한다면, 인바운드 TCP가 네임스페이스에 도달하고 있다는 의미입니다. 타임아웃이 발생한다면 도달하지 못하는 것이며, 원인은 클라이언트 상위 계층에 있습니다. CTRL+C를 눌러 도구를 중지하고 exit을(를) 입력하여 셸을 종료한 뒤, 클라이언트를 다시 시작하십시오. 이 테스트는 TCP만 확인합니다. DHT(분산 해시 테이블) 및 uTP 트래픽은 동일한 포트 번호에서 UDP를 사용하며, 이 테스트는 이를 포함하지 않습니다.

실패 유형 및 확인되는 메시지

로그에 포트 관련 줄이 전혀 없음. 포트를 요청하는 과정이 없었습니다. docker exec gluetun printenv | grep PORT_FORWARDING을 사용하여 변수가 컨테이너에 정상적으로 전달되었는지 확인하십시오. 잘못된 compose 서비스에 변수를 설정하는 경우가 흔한 원인입니다.

Gluetun이 시작되지 않고 제공자(provider) 관련 오류를 출력함. VPN_PORT_FORWARDING_PROVIDER는 지원되는 4가지 이름과 대조하여 검증되므로, 오타가 있으면 포워딩 없이 조용히 실행되는 대신 컨테이너가 즉시 중단됩니다.

로그에 no port forwarded가 표시됨. Gluetun이 요청했으나 제공자로부터 아무런 응답을 받지 못했습니다. ProtonVPN의 경우, 일반적으로 생성한 설정에서 NAT-PMP가 활성화되지 않았거나 해당 요금제에서 포트 포워딩을 지원하지 않음을 의미합니다. Private Internet Access의 경우, 선택한 서버가 해당 기능을 제공하지 않는 경우가 많습니다.

포트는 할당되었으나 연결이 되지 않음. 위 두 명령어를 사용하여 포워딩된 포트와 클라이언트의 리스닝 포트를 비교하십시오. 두 포트가 일치한다면, 클라이언트가 터널 인터페이스에 바인딩되어 있는지, 그리고 random-port 옵션이 꺼져 있는지 확인하십시오. 해당 옵션이 켜져 있으면 시작할 때마다 리스닝 포트가 변경됩니다.

up 명령어가 아무런 동작을 하지 않는 것처럼 보임. 컨테이너 내부에서 다음 명령어를 직접 실행하여 오류를 확인하십시오: docker exec gluetun /bin/sh -c '<your command>'. 이미지는 wget만 포함하고 있으므로, 보통 curl: not found 결과가 나타납니다.

제어 서버로부터 401 Unauthorized 오류 발생. 인증 설정을 정의했으나 호출하려는 경로가 역할(role)에 나열되어 있지 않습니다. 경로는 메서드와 경로를 조합하여 일치 여부를 판단하므로, 역할에 /v1/portforward만 나열되어 있다면 GET /v1/portforward에 대한 접근은 허용되지 않습니다.

재시작할 때마다 Private Internet Access에서 다른 포트가 할당됨. /gluetun를 바인드 마운트하여 저장된 포트 상태가 재시작 후에도 유지되도록 하십시오. 해당 볼륨이 없으면 Gluetun은 매번 새로운 포트를 요청합니다.

FAQ

토렌트 다운로드는 되는데 왜 수신 연결은 하나도 되지 않습니까?

포트 포워딩이 설정되지 않으면 VPN 제공업체는 어떤 포트로 들어오는 패킷도 사용자의 터널로 전달하는 NAT 규칙을 생성하지 않습니다. 따라서 사용자가 직접 시작하지 않은 연결은 모두 출구 주소에서 차단됩니다. 다운로드가 가능한 이유는 클라이언트가 직접 연결을 생성하며, 연결 가능한 다른 피어에 접근할 수 있기 때문입니다. 하지만 시딩이나 스웜 참여는 다른 사용자가 사용자에게 접근해야 하므로 정상적으로 작동하지 않습니다. 해결 방법은 포트 포워딩을 지원하는 제공업체를 선택하고, gluetun에서 VPN_PORT_FORWARDING=on을 설정한 뒤, 해당 포트를 클라이언트의 수신 포트로 적용하는 것입니다.

gluetun은 모든 VPN 제공업체의 포트 포워딩과 호환됩니까?

아니요. gluetun v3.41.3은 Private Internet Access, ProtonVPN, Perfect Privacy, PrivateVPN 등 4개 제공업체에 대한 기본 통합 기능을 제공합니다. 이 목록에 없는 제공업체를 사용하면 VPN_PORT_FORWARDING_PROVIDER 설정 시 유효성 검사에 실패하며 컨테이너가 시작되지 않습니다. 제공업체 제어판에서 고정 포트를 할당받는 경우 gluetun이 이를 대신 요청할 수는 없지만, FIREWALL_VPN_INPUT_PORTS를 사용하면 해당 고정 포트를 gluetun 방화벽에서 허용할 수 있습니다. 제공업체의 정책은 수시로 변경되므로 플랜을 구매하기 전에 현재 제공업체 페이지를 확인하십시오.

재연결할 때마다 포트를 업데이트해야 합니까?

네, 업데이트는 자동으로 이루어져야 합니다. 포트 포워딩은 VPN 세션에 종속되므로 컨테이너 재시작, 서버 변경, 임대 갱신 실패 시 새로운 포트 번호가 할당될 수 있지만, 클라이언트는 이전 포트 번호를 설정에 그대로 유지하기 때문입니다. 포워딩이 활성화되는 즉시 실행되는 VPN_PORT_FORWARDING_UP_COMMAND을 통해 gluetun이 포트를 전달하게 하거나, 제어 서버에서 GET /v1/portforward을 읽어와 클라이언트 API를 통해 값을 업데이트하는 별도의 프로세스를 실행하십시오.

포트 포워딩이 실제로 열려 있는지 어떻게 확인합니까?

gluetun의 네트워크 네임스페이스 내부에서 해당 포트로 리스너를 실행한 뒤, VPN 외부에서 연결을 시도하십시오. 포트를 확보하기 위해 먼저 토렌트 클라이언트를 중지하고, gluetun 컨테이너 내부에서 --listening-address=":<port>"을 사용하여 업스트림 포트 확인 바이너리를 실행합니다. curl -s http://127.0.0.1:8000/v1/publicip/ip에서 출구 주소를 확인한 뒤, 모바일 데이터를 사용하는 휴대폰에서 http://<address>:<port>에 접속하십시오. 포트 확인 로그에 요청이 기록되면 인바운드 TCP 연결이 정상적으로 도착하는 것입니다. 타임아웃이 발생하면 클라이언트 상태 아이콘에 표시되는 내용과 관계없이 연결이 차단된 상태입니다.

#gluetun #vpn#port-forwarding#docker#torrenting