WireGuard를 설정할 때는 먼저 로컬 기기와 상대방의 키, 외부 연결 주소를 구분한 다음 터널 내부 Address를 확인합니다. 서비스 제공업체에서 받은 설정값이 있는 사용자를 대상으로, 항목별 값을 대응해 입력하고 기본 MTU를 기준으로 연결을 확인합니다. 이어 DNS, UDP 연결 가능 여부, 유휴 상태 이후의 복구를 각각 점검해 모든 연결 문제를 키나 MTU 탓으로 돌리지 않도록 합니다.
키, 터널 주소, Endpoint 구분하기
Shadowrocket에서 WireGuard 유형을 선택했다고 해서 연결이 바로 작동하는 것은 아닙니다. WireGuard는 키로 통신 상대를 식별하고 UDP로 캡슐화된 데이터를 전송합니다. 서버에도 클라이언트의 PublicKey를 등록하고 할당된 터널 주소를 사용할 수 있도록 설정해야 합니다. 클라이언트 항목을 빠짐없이 입력하더라도 서버의 피어 설정을 대신할 수는 없습니다.
이 문서에서는 [Interface]와 [Peer]에 사용하는 표준 WireGuard 필드의 의미를 설명합니다. 이 이름은 설정 파일에서 사용하는 것으로, Shadowrocket 편집 화면의 그룹이나 표기가 반드시 같다는 뜻은 아닙니다. 입력할 때는 앱에 실제로 표시되는 항목을 기준으로 확인하세요. 특히 Address라는 이름만 보고 서버 주소인지 터널 내부 주소인지 판단해서는 안 됩니다.
예를 들어 192.0.2.10:51820은 Endpoint의 ‘호스트 주소와 포트’ 구조를, 10.66.0.2/32는 터널 내부 IPv4 주소의 구조를 설명하는 데 사용할 수 있습니다. 앞의 주소는 문서용 예시이며 두 값 모두 이 문서에서 제공하는 연결 정보가 아닙니다. 실제 값은 사용자가 이미 보유한 설정에서 확인해야 합니다. 포트 51820은 흔히 드는 예시일 뿐, 모든 WireGuard 서비스가 이 포트를 사용하는 것은 아닙니다.
PrivateKey와 PublicKey 값의 출처
PrivateKey는 현재 클라이언트의 개인 키입니다. 이에 대응하는 클라이언트 PublicKey는 서버에 등록해야 합니다. 클라이언트의 [Peer]에 필요한 PublicKey는 서버의 공개 키입니다. 이 두 방향을 혼동하기 쉽습니다. 자신의 공개 키를 상대방 공개 키 항목에 입력하면 형식이 올바르더라도 의도한 인증을 완료할 수 없습니다.
로컬 기기의 키와 주소
- PrivateKey
- 현재 클라이언트 설정에서 가져오는 개인 키입니다. 안전하게 보관하세요.
- 클라이언트 PublicKey
- 로컬 PrivateKey에 대응하는 공개 키로, 서버에 등록합니다.
- Address
- 서버가 할당한 터널 내부 주소입니다. 예: 10.66.0.2/32
로컬 개인 키, 서버에 등록된 클라이언트 공개 키, 할당된 주소가 서로 일치해야 합니다.
상대방 연결 정보
- PublicKey
- 상대 서버의 공개 키입니다. 클라이언트 자신의 공개 키가 아닙니다.
- Endpoint
- 서버의 호스트 이름 또는 IP 주소와 실제 UDP 포트입니다.
- PresharedKey
- 선택 항목인 사전 공유 키입니다. 기존 설정에서 요구하는 경우에만 입력합니다.
PresharedKey는 PrivateKey나 PublicKey로 대체할 수 없으며 임의로 값을 추가해서도 안 됩니다.
WireGuard 키의 일반적인 Base64 텍스트는 44자이며 끝에 =가 붙는 경우가 많습니다. 이는 입력 형식을 확인할 때 참고할 수 있을 뿐, 키가 올바른 상대방의 것인지 증명하지는 않습니다. 복사할 때 불필요한 공백, 줄바꿈, 따옴표가 들어가지 않았는지 확인하세요. 길이를 맞추려고 문자를 임의로 추가하거나 삭제하지 마세요. 키가 유출됐다면 해당 키를 교체하고 서버 등록 정보도 함께 갱신해야 합니다. 노드 메모만 수정해서는 해결되지 않습니다.
Home에서 WireGuard 추가하기: 확인 절차
현재 작동하는 설정은 그대로 두고, 확인용 항목을 새로 추가하세요. 아래 단계는 수동 입력을 기준으로 합니다. 기존 구독에서 설정을 가져온 경우 실제로 WireGuard 유형으로 생성됐는지 먼저 확인하세요. WireGuard 설정 텍스트를 구독 URL만 입력할 수 있는 칸에 붙여 넣거나, 모든 설정 형식을 동일한 가져오기 메뉴에서 인식할 수 있다고 가정하지 마세요.
-
유형 선택
Home → 오른쪽 위 ‘+’ → Type → WireGuard로 이동합니다. 다른 프로토콜의 편집 화면에 같은 이름의 항목을 적용하지 않도록, 매개변수를 입력하기 전에 유형을 확인하세요.
-
상대방 정보 입력
기존 설정의 Endpoint에 있는 호스트와 포트를 각각 서버 주소와 포트 항목에 입력합니다. 예를 들어 192.0.2.10:51820은 호스트가 192.0.2.10이고 UDP 포트가 51820이라는 뜻입니다. 여기서는 값을 나누는 방법만 설명합니다.
-
키 연결 확인
로컬 PrivateKey, 상대방 PublicKey, 기존 설정에서 요구하는 PresharedKey를 입력합니다. 각 값의 출처를 확인하고 클라이언트 공개 키와 서버 공개 키를 서로 바꿔 입력하지 마세요.
-
주소 확인
할당된 터널 내부 Address를 로컬 주소 항목에 입력합니다. 기존 설정에 IPv4와 IPv6가 모두 포함되어 있다면 각각 확인하세요. 화면에서 주소와 prefix를 따로 입력하는 경우 실제 항목에 맞춰 입력합니다.
-
저장 후 확인
저장한 다음 Home으로 돌아가 해당 항목을 선택하고 Global Routing을 확인합니다. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 승인한 뒤, 연결 스위치만 보지 말고 실제 요청으로 연결을 확인하세요.
구독 관리 항목은 다음 업데이트 때 원본 설정으로 다시 덮어써질 수 있습니다. MTU나 keepalive 간격을 시험하려면 기존 값을 먼저 기록하고 별도로 유지할 수 있는 테스트 항목을 사용하세요. 수정 내용이 사라졌다면 키를 반복해서 다시 입력하기 전에 구독 업데이트가 있었는지 확인합니다. Shadowrocket의 Home, Config, Settings는 각각 연결 선택, 구성 관리, 앱 설정을 담당합니다. 노드를 수정해도 현재 선택된 Config가 자동으로 바뀌지는 않습니다.
Address, AllowedIPs와 트래픽 분기 규칙의 차이
Address는 터널 인터페이스의 로컬 주소이며 DNS 주소나 서버의 공인 IP가 아닙니다. 접미사 /32는 IPv4 호스트 주소 하나, /128은 IPv6 호스트 주소 하나를 뜻합니다. 서비스 제공업체가 할당한 주소를 임의로 다른 기기의 주소로 바꾸지 마세요. 동일한 키나 주소를 중복 사용하면 응답이 전달되는 위치가 바뀌거나 연결이 간헐적으로 끊길 수 있습니다.
| 설정 항목 | 의미 | 이 항목만으로 판단할 수 없는 내용 |
|---|---|---|
| Address | 로컬 터널 주소(예: 10.66.0.2/32) | 공인 서버 주소로 사용할 수 없습니다. |
| Endpoint | 외부 UDP 데이터가 전송되는 호스트와 포트 | 포트가 열려 있어도 키 페어링이 성공했다는 뜻은 아닙니다. |
| AllowedIPs | 표준 WireGuard에서 상대방 주소를 선택하고 수신 출처를 제한하는 설정 | Shadowrocket의 도메인 트래픽 분기 규칙과 같은 의미가 아닙니다. |
| Global Routing | Shadowrocket에서 현재 선택된 전체 라우팅 방식 | WireGuard 항목을 선택해도 모든 요청이 해당 항목을 사용하는 것은 아닙니다. |
표준 WireGuard 설정에서 0.0.0.0/0과 ::/0은 각각 전체 IPv4와 IPv6 주소 범위를 포함합니다. 하지만 WireGuard를 Shadowrocket 노드로 사용할 때 요청이 실제로 이 노드로 전달되는지는 Global Routing, 현재 Config, 적용된 정책을 함께 확인해야 합니다. 원본 파일에 이 두 범위가 있다는 이유만으로 앱의 모든 트래픽이 해당 노드를 사용한다고 판단하지 마세요.
DOMAIN-SUFFIX는 도메인 접미사로 일치 항목을 찾으며 WireGuard 키를 검증하지 않습니다.IP-CIDR은 대상 IP 대역으로 일치 항목을 찾는 규칙이며 로컬 인터페이스에 Address를 할당하지 않습니다.GEOIP는 IP 주소의 지역 정보를 기준으로 일치 항목을 찾으며 Endpoint의 UDP 연결 문제를 해결하지 않습니다.FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 기본 규칙입니다. 이 규칙의 정책이 현재 WireGuard 노드라는 보장은 없습니다.
MTU: 기준값을 유지하고 대용량 패킷 문제를 확인하기
MTU는 터널 인터페이스가 전송할 수 있는 최대 IP 패킷 크기이며, 속도 제한이 아닙니다. WireGuard로 데이터를 캡슐화하면 외부 IP, UDP, 프로토콜 오버헤드가 추가됩니다. 하위 네트워크 경로가 더 작은 패킷만 처리할 수 있고 경로 MTU 탐색도 제대로 작동하지 않으면 작은 요청은 성공하지만 큰 응답은 멈출 수 있습니다. 핸드셰이크는 정상인데 페이지 리소스가 끝까지 로드되지 않는다면 MTU를 점검해 볼 수 있지만, 그것만으로 원인을 단정해서는 안 됩니다.
기본값 또는 기존 설정 유지
권장첫 테스트에서는 앱의 기본 처리 방식이나 기존 설정에 명시된 MTU를 그대로 사용하고 키, 주소, Endpoint가 정상 작동하는지 먼저 확인하세요. 이렇게 얻은 결과를 이후 테스트의 기준으로 삼을 수 있습니다.
적합한 경우: 처음 설정할 때, 연결이 정상일 때, 대용량 패킷 문제가 아직 없을 때
MTU만 낮춰 보기
현재 값이 목표값보다 높은 경우에만 낮은 값을 시도하세요. 예를 들어 1420에서 1380으로 바꾼 뒤 동일한 요청을 다시 테스트할 수 있습니다. 두 값은 문제 해결을 위한 예시이지 보편적인 최적값이 아닙니다. 한 번에 MTU만 변경하고 원래 값을 복구할 수 있도록 기록해 두세요.
적합한 경우: 작은 요청은 성공하지만 큰 응답이나 특정 네트워크에서 반복적으로 멈출 때
기존 값으로 되돌려 재확인
값을 낮춰도 문제가 달라지지 않으면 원래 값으로 되돌리고 UDP 연결 가능 여부, DNS, 서버 라우팅을 확인하세요. MTU가 낮으면 패킷 수가 늘어날 수 있으며, 계속 값을 낮춘다고 모든 문제가 해결되는 것은 아닙니다.
적합한 경우: 변경 효과가 없거나 다른 매개변수 때문에 같은 문제가 생긴 경우
IPv6를 사용하는 터널의 인터페이스 MTU를 임의로 1280 미만으로 낮추지 마세요. 1280은 IPv6 최소 링크 MTU의 중요한 기준입니다. 문제를 확인하는 동안에는 동일한 Wi-Fi와 동일한 대상 요청을 사용하는 등 나머지 조건을 일정하게 유지하고 변경 전후의 증상을 기록하세요. 이 문서의 수치는 테스트 방법을 설명하기 위한 예시이며 특정 경로에서 측정된 결과나 성능을 보장하지 않습니다.
DNS와 PersistentKeepalive의 역할
DNS는 도메인 이름을 IP 주소로 변환합니다. WireGuard 핸드셰이크가 성공했다고 해서 도메인 이름도 정상적으로 확인된다는 뜻은 아닙니다. Endpoint에 호스트 이름을 사용한다면 외부 연결을 시작하기 전에 해당 이름도 조회해야 합니다. ‘서버 호스트 이름을 확인할 수 없음’과 ‘터널이 연결된 뒤 방문하려는 도메인을 확인할 수 없음’은 서로 다른 단계이며, 조회 경로도 다를 수 있습니다.
표준 WireGuard 설정에서 DNS는 설정 도구에서 사용하는 보조 설정이며 WireGuard 핸드셰이크 프로토콜의 일부가 아닙니다. 노드를 Shadowrocket에서 사용할 때 원본 설정의 DNS 항목이 앱의 이름 확인 동작을 모두 제어한다고 가정하지 마세요. 현재 Config의 DNS 설정도 확인해야 합니다. DNS 주소에 터널 내부에서만 접근할 수 있다면 먼저 해당 주소로 연결되는 올바른 경로가 있어야 합니다.
- 도메인 접속은 실패하지만 IP 주소로는 연결됨: 먼저 DNS 서버, 조회 경로, IPv4 및 IPv6 응답을 확인하세요. 이는 진단을 위한 단서일 뿐 최종 결론은 아닙니다.
- Endpoint에 도메인을 사용하며 연결을 시작할 수 없음: 터널 내부 DNS를 바꾸기 전에 현재 네트워크에서 호스트 이름을 확인할 수 있는지 테스트하고 UDP 포트를 점검하세요.
- 유휴 상태 후 첫 요청이 멈춤: 키를 바로 다시 만들기보다 NAT 매핑이 만료됐는지 확인한 뒤 PersistentKeepalive를 검토하세요.
- 네트워크 전환 후 복구가 느림: Wi-Fi와 셀룰러 네트워크에서 각각 동작을 기록해 Endpoint의 UDP 트래픽을 제한하는 네트워크가 있는지 확인하세요.
PersistentKeepalive의 단위는 초입니다. 유휴 상태에서 keepalive 데이터를 보내 NAT 또는 방화벽 매핑을 유지합니다. 25초는 흔히 참고하는 간격일 뿐 필수값은 아니며, 표준 설정에서 0은 주기적 keepalive를 사용하지 않는다는 뜻입니다. 간격을 짧게 하면 유휴 상태의 네트워크 활동이 늘어납니다. 간격을 줄인다고 연결이 반드시 안정되는 것은 아니므로 기존 설정과 네트워크 증상에 따라 결정하세요.
매개변수를 한꺼번에 바꾸지 말고 실패 단계별로 확인하기
Home에서 연결이 켜졌다고 표시되면 시스템 VPN 터널이 시작된 것은 확인할 수 있지만, WireGuard 상대방이 응답했다는 뜻은 아닙니다. 지연 시간 테스트 결과도 테스트 방식과 함께 해석해야 합니다. 한 번 시간 초과가 발생했다고 해서 UDP 연결 불가, 키 불일치, 테스트 대상의 무응답 중 어느 문제인지 구분할 수는 없습니다. 연결 설정, 데이터 전송, 도메인 확인, 유휴 상태 후 복구 중 어느 단계에서 실패했는지 확인하세요.
| 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 유효한 응답이 전혀 없음 | Endpoint, UDP 포트, 양쪽 공개 키 페어링, PresharedKey | Wi-Fi와 셀룰러 네트워크에서 각각 테스트하고 서버 등록 정보를 확인합니다. |
| 응답은 있지만 대상에 연결할 수 없음 | 터널 Address, 서버 포워딩, 현재 선택된 노드와 정책 | 요청이 실제로 해당 노드를 통과하는지 확인한 다음 서버 라우팅을 점검합니다. |
| 도메인으로만 접속할 수 없음 | Endpoint 이름 확인과 대상 도메인 이름 확인이 이루어지는 단계 | 같은 라우팅 조건에서 DNS 응답과 알려진 IP 주소의 연결 가능 여부를 비교합니다. |
| 작은 응답은 정상이나 큰 응답은 멈춤 | 경로 MTU, IPv6 경로, 중간 네트워크 제한 | MTU만 변경하고 같은 테스트를 반복한 뒤 결과를 기록합니다. |
| 한동안 유휴 상태였다가 연결이 끊김 | NAT 매핑, PersistentKeepalive, 네트워크 전환 | 유휴 시간을 기록하고 기존 설정에 따라 keepalive를 조정한 뒤 다시 테스트합니다. |
규칙 때문에 테스트 트래픽이 해당 노드를 우회한다고 의심된다면 Home → Global Routing에서 일시적으로 Proxy를 선택하고 테스트할 WireGuard 항목이 선택되어 있는지 확인할 수 있습니다. 이렇게 하면 규칙에 따른 트래픽 분기를 변수에서 제외하는 데 도움이 될 뿐, 노드 자체의 문제를 해결하지는 않습니다. 테스트가 끝나면 기존 Config나 라우팅 설정으로 되돌려 진단용 설정이 평소 설정으로 남지 않도록 하세요.
WireGuard 포트를 443으로 바꾸면 연결이 더 잘 되나요?
상대 서버가 해당 UDP 포트에서 실제로 수신 대기하는 경우에만 변경할 수 있습니다. UDP 443과 TCP 443은 서로 다른 전송 종단점입니다. 어떤 웹페이지가 TCP 443으로 열린다고 해서 현재 네트워크에서 같은 주소의 UDP 443도 허용된다는 뜻은 아닙니다. 포트를 추측해서 바꾸지 말고 기존 설정을 확인하세요.
같은 WireGuard 설정을 iPhone과 iPad에 그대로 복사해도 되나요?
두 기기에서 같은 키와 터널 주소를 동시에 재사용할 수 있다고 가정하지 마세요. 상대방은 최근에 받은 유효한 패킷에 따라 통신 Endpoint를 갱신할 수 있어, 설정을 재사용하면 두 기기의 연결에 서로 영향을 줄 수 있습니다. 서비스 제공업체가 각 기기에 할당한 키와 주소를 사용하세요. 앱 구매 적용 범위와 프로토콜 키 할당은 별개의 문제입니다.
문제 해결이 끝나면 키를 제외한 변경 기록을 남기세요. 어떤 항목을 바꿨는지, 변경 전후 값, 사용한 네트워크, 어떤 요청이 정상화됐는지를 기록하면 됩니다. 모든 네트워크에서 유효한 응답을 받지 못하면 Endpoint와 키 페어링부터 다시 확인하세요. 특정 유형의 요청만 실패한다면 DNS, 트래픽 분기, MTU를 점검합니다. 여러 매개변수를 동시에 바꾸는 것보다 이 순서로 확인해야 재현 가능한 결론을 얻기 쉽습니다.