이 글의 핵심 내용

사용 권한이 있는 WireGuard 설정을 보유하고 있으며 Shadowrocket에서 필드를 확인하려는 사용자를 위한 안내입니다. 먼저 기기의 PrivateKey와 상대편의 PublicKey를 구분한 뒤 Endpoint, 터널 주소, AllowedIPs를 입력하고 마지막으로 Global Routing이 규칙에 미치는 영향을 확인합니다. 이 글은 설정 항목과 점검 순서를 설명하며 연결 정보는 제공하지 않습니다. 예시 주소는 형식 설명용이며 실제 연결에 사용할 수 없습니다.

1. WireGuard 설정의 양쪽 구성부터 구분하기

WireGuard 설정은 보통 [Interface]와 하나 이상의 [Peer] 섹션으로 구성됩니다. 앞부분은 내 기기의 터널 인터페이스를, 뒷부분은 통신을 허용할 상대편을 설명합니다. 설정을 Shadowrocket에 옮길 때는 각 필드가 속한 위치에 맞춰 입력하세요. 설정에 처음 나오는 PublicKey를 무조건 서버 키로 간주하면 안 됩니다.

WireGuard는 UDP로 통신합니다. Endpoint 포트는 상대편 설정에 따라 다르며, 51820은 흔히 쓰이는 예시일 뿐 고정 포트가 아닙니다. 웹사이트에 접속되거나 일반 TCP 포트 테스트에 응답이 있다고 해서 현재 네트워크에서 WireGuard UDP 통신이 가능하다고 단정할 수는 없습니다.

UDP
WireGuard 전송 프로토콜
32바이트
디코딩한 공개 키와 개인 키의 길이
51820
이 글의 Endpoint 예시 포트이며 필수값이 아닙니다

키는 보통 Base64 텍스트로 표시됩니다. 32바이트 값은 인코딩 후 대개 44자로 나타나며 끝에 =가 붙습니다. 이 길이는 복사 과정에서 내용이 크게 누락됐는지 확인하는 데만 참고할 수 있으며, 키가 올바른 기기나 상대편의 것인지는 증명하지 못합니다. PrivateKey, PresharedKey 또는 이러한 키가 포함된 QR 코드를 공개 게시판에 올리지 마세요.

2. PrivateKey, PublicKey, PresharedKey의 관계

필드입력할 값자주 하는 실수
PrivateKey현재 클라이언트에 해당하는 개인 키입니다. 클라이언트의 [Interface] 섹션에서 가져옵니다.서버의 개인 키를 입력하거나, 키를 새로 만든 뒤 클라이언트 공개 키를 상대편 설정에 등록하지 않는 경우입니다.
PublicKey대상 [Peer]의 공개 키, 즉 연결할 상대편의 공개 키입니다.PrivateKey에서 파생된 이 기기의 공개 키를 입력하는 경우입니다.
PresharedKey양쪽이 별도로 합의한 사전 공유 키입니다. 원래 설정에 있을 때만 입력하세요.한쪽에만 값이 설정되어 있거나 PrivateKey와 혼동하는 경우입니다.
Address이 기기에 할당된 터널 내부 주소입니다. 예: 10.66.0.2/32.Endpoint의 공인 주소를 잘못 입력하거나 다른 기기의 터널 주소를 중복 사용하는 경우입니다.

PrivateKey가 이 기기의 신원을 결정하며, 이에 대응하는 클라이언트 공개 키는 상대편 설정에 등록해야 합니다. Shadowrocket에서 PrivateKey만 바꾸고 상대편에는 이전 공개 키가 그대로 남아 있으면 핸드셰이크가 완료되지 않는 경우가 많습니다. PublicKey는 비밀번호나 임의로 붙이는 이름이 아닙니다. 실제 상대편의 개인 키와 짝을 이루어야 합니다.

키를 복사할 때 대소문자, 더하기 기호, 슬래시, 끝의 등호를 그대로 유지하고 실수로 포함된 따옴표와 줄바꿈은 제거하세요. 키가 유출됐다면 새 키로 교체하고 상대편 등록 정보도 갱신해야 합니다. 채팅 기록만 삭제해도 기존 키가 무효화되지는 않습니다.

3. Endpoint, AllowedIPs, DNS, MTU의 역할

Endpoint는 암호화된 통신 경로를 설정할 때 접속할 외부 주소이며 터널 내부 주소가 아닙니다. IPv4 예시는 192.0.2.10:51820입니다. IPv6 주소와 포트를 한 항목에 입력한다면 [2001:db8::10]:51820처럼 작성합니다. 화면에서 주소와 포트를 따로 입력하는 경우 주소 칸에는 호스트 이름이나 IP만, 포트 칸에는 숫자만 입력하세요.

설정 항목의미확인 방법
AllowedIPsWireGuard Peer에서 사용할 주소 범위와 수신 트래픽의 출처를 제한하는 설정입니다.클라이언트의 목적지 주소가 해당 Peer의 범위에 포함되는지 확인하세요. 상대편이 클라이언트의 터널 출발지 주소를 허용하는지도 함께 점검해야 합니다.
DNS일반 설정 파일에 포함되는 DNS 리졸버 설정으로, WireGuard 핸드셰이크 자체와는 별개입니다.현재 네트워크 경로에서 리졸버 주소에 접근할 수 있는지 확인하고 Shadowrocket의 현재 Config에서 DNS 설정을 점검하세요.
MTU터널 인터페이스가 처리할 수 있는 IP 패킷의 최대 크기입니다.먼저 설정 제공자가 지정한 값을 유지하세요. 큰 요청은 멈추고 작은 요청은 정상일 때 MTU를 따로 조정해 보세요.
PersistentKeepalive유휴 상태에서 주기적으로 전송하는 keepalive 패킷의 간격입니다. 단위는 초입니다.NAT 매핑을 유지해야 한다면 설정 제공자의 요구에 따라 사용하세요. 예: 25. 잘못된 키를 해결하는 설정은 아닙니다.

AllowedIPs는 Shadowrocket의 전체 트래픽 분기 규칙이 아닙니다

0.0.0.0/0은 모든 IPv4 주소를 포함하고 ::/0은 모든 IPv6 주소를 포함합니다. 앞의 값만 입력해도 IPv6까지 포함되는 것은 아닙니다. 10.66.0.0/24만 입력하면 해당 네트워크 범위만 포함됩니다. 사용 목적과 상대편이 처리할 수 있는 범위에 맞춰 설정하고, 빠짐없이 보이게 하려고 범위를 무작정 넓히지 마세요.

Shadowrocket에서는 Global Routing과 현재 Config가 먼저 연결에 사용할 경로를 결정합니다. 연결이 WireGuard 출구로 전달된 뒤에는 해당 Peer의 주소 범위도 충족해야 합니다. 따라서 AllowedIPs에 특정 IP가 포함되어 있어도 그 주소로 접속할 때 WireGuard 항목이 자동 선택되는 것은 아닙니다. 반대로 규칙에서 해당 항목을 선택해도 누락된 AllowedIPs 범위가 자동으로 추가되지는 않습니다.

# 주소 형식을 설명하기 위한 예시일 뿐이며, 그대로 가져올 수 있는 완성된 설정은 아닙니다.
# 아래 주소는 예시이며 실제 서비스와 연결되지 않습니다.
[Interface]
Address = 10.66.0.2/32
MTU = 1420

[Peer]
Endpoint = 192.0.2.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

1420은 흔히 참고하는 MTU 값일 뿐 모든 네트워크에 가장 적합한 값은 아닙니다. 핸드셰이크는 정상인데 큰 응답이 멈춘다면 기존 값을 기록한 뒤 1380처럼 더 작은 값으로 바꿔 같은 요청을 다시 테스트하고, 유지할지 결정하세요. MTU, DNS, 키를 한꺼번에 변경하면 어떤 변경이 영향을 줬는지 알기 어렵습니다. 원본 파일의 DNS나 MTU 설정이 가져오기 방식에 관계없이 모두 자동 적용된다고 가정해서도 안 됩니다.

4. Shadowrocket에 WireGuard 추가하기: 확인 순서

아래는 Home, Config, Settings 구성에 따라 수동으로 추가하는 순서입니다. 플랫폼마다 필드 배치와 저장 버튼 위치가 다를 수 있으므로 영문 필드의 의미에 맞춰 하나씩 입력하세요. 여러 Peer가 있는 설정이라면 연결 항목 하나를 수동으로 추가해도 모든 Peer 선택 관계가 복원된다고 가정하지 마세요. 먼저 이번에 사용할 상대편을 확인해야 합니다.

  1. 원본 설정 정리

    [Interface]와 대상 [Peer]를 구분하고 클라이언트 PrivateKey, Address, 상대편 PublicKey, Endpoint, AllowedIPs를 준비하세요. 원본 설정에 PresharedKey가 있다면 함께 준비합니다.

  2. 유형 선택

    Home → 오른쪽 위 「+」→ Type → WireGuard로 이동합니다. 알아보기 쉬운 이름을 지정해 기존 연결 항목과 혼동하거나 잘못 선택하지 않도록 하세요.

  3. 필드 입력

    각 키와 주소를 이 기기 또는 Peer에 속하는 위치에 맞춰 입력하세요. Endpoint가 주소와 포트로 나뉘어 있다면 각각 입력합니다. AllowedIPs의 CIDR 접두사 길이를 유지하고, 제공되지 않은 PresharedKey를 임의로 만들지 마세요.

  4. 저장 후 선택

    저장한 다음 Home으로 돌아가 새로 추가한 WireGuard 항목을 선택합니다. 현재 Global Routing 값도 확인한 뒤 연결을 켜세요. 처음 표시되는 시스템 권한 안내는 기기 화면에 따라 확인하면 됩니다.

  5. 테스트 후 설정 복원

    접근 권한이 있고 AllowedIPs 범위에 포함되는 대상으로 테스트하세요. 점검을 마친 뒤 평소 사용하는 Global Routing 설정으로 되돌립니다. Config에서 실제 규칙이 참조하는 정책이 예상한 출구를 가리키는지도 확인하세요.

5. Global Routing으로 설정 오류와 규칙 영향을 구분하기

진단을 시작하기 전에 Home → Global Routing의 현재 값을 기록하세요. Config, Proxy, Direct, Scene은 라우팅 모드이며 WireGuard 키 설정이 아닙니다. Scene은 구성된 시나리오에 따라 동작하므로 시나리오 내용을 확인하기 전에는 고정된 테스트 경로라고 간주하지 마세요.

Config

추천

현재 Config 규칙에 따라 정책을 선택합니다. DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL 등의 규칙은 목적지에 따라 서로 다른 출구로 연결할 수 있습니다. 해당 정책에 매칭된 연결만 이 WireGuard 항목을 사용합니다.

적합한 경우: 규칙을 확인한 뒤 일상적인 트래픽 분기에 사용할 때.

Proxy

Shadowrocket이 처리하는 연결을 선택한 프록시 경로로 보냅니다. Config 규칙의 선택으로 생기는 변수를 줄이는 데 쓸 수 있습니다. 단, 선택한 항목이 대상 WireGuard인지, 대상 주소가 해당 항목의 AllowedIPs 범위에 포함되는지 확인해야 합니다.

적합한 경우: 지정한 테스트 대상에 WireGuard 출구로 접속할 수 있는지 잠시 확인할 때.

Direct

직접 연결 경로를 사용합니다. 이 상태에서 웹페이지가 열려도 직접 연결로 접근 가능하다는 뜻일 뿐, WireGuard 설정이 성공했다는 증거는 아닙니다. 해당 Peer의 출구 상태를 판단하는 데도 사용할 수 없습니다.

적합한 경우: 기기의 기존 네트워크에서 기본 연결이 되는지 비교할 때.

Proxy에서 지정한 대상에 접근할 수 있지만 Config로 전환한 뒤 실패한다면 먼저 해당 대상에 적용된 규칙과 정책을 확인하세요. PrivateKey부터 바꾸지 마세요. Proxy에서도 실패한다면 Endpoint, UDP 연결 가능 여부, 양쪽 키, AllowedIPs를 다시 점검하세요. Settings → On Demand는 조건에 따라 연결을 시작하는 동작을 관리하며 Peer 키를 변경하지 않습니다. 자동 재연결이 점검에 영향을 주는 것 같다면 상태를 기록한 뒤 잠시 끄고 연결을 수동으로 제어하세요.

6. 핸드셰이크 실패, 도메인 접속 불가, 유휴 연결 끊김 점검

연결 스위치를 켰는데도 왜 접속할 수 없나요?

스위치를 켰다고 Peer와 유효한 통신이 완료된 것은 아닙니다. 먼저 Home에서 대상 WireGuard 항목을 선택했는지 확인한 뒤 Endpoint 주소와 UDP 포트, 클라이언트 PrivateKey에 대응하는 공개 키가 상대편에 등록되어 있는지, PublicKey가 실제 상대편의 것인지 점검하세요. 로그나 상대편 핸드셰이크 기록을 볼 수 있다면 테스트를 시작한 뒤 새로운 유효 핸드셰이크가 나타나는지 확인하세요. 연결 스위치만 보고 판단하지 마세요.

핸드셰이크 기록은 있는데 웹페이지가 열리지 않나요?

양쪽 AllowedIPs를 확인하세요. 클라이언트 범위가 목적지 주소를 포함하는지, 상대편이 이 기기의 터널 출발지 주소를 허용하는지 점검합니다. 목적지가 상대편 뒤쪽 네트워크에 있다면 네트워크 관리자에게 전달 설정, 방화벽, 반환 경로, 필요한 NAT를 확인하도록 요청하세요. 핸드셰이크는 키와 기본 UDP 경로가 작동한다는 뜻이지, 상대편이 목적지 네트워크로 트래픽을 전달할 수 있다는 보장은 아닙니다.

IP 주소로는 접속되는데 도메인 이름은 해석에 실패하나요?

Config에서 현재 DNS 설정과 리졸버 연결 여부를 확인하고 Endpoint 호스트 이름의 해석 실패와 서비스 도메인의 해석 실패를 구분하세요. IP 주소로 직접 테스트할 때는 원래 IP 접속을 지원하는 대상을 선택해야 합니다. HTTPS 사이트는 인증서나 가상 호스트 설정 때문에 IP 주소 직접 접속을 거부할 수 있으므로 이런 오류를 곧바로 DNS 문제로 판단하면 안 됩니다.

잠시 두면 연결이 끊기지만 다시 연결하면 정상인가요?

먼저 Wi-Fi와 모바일 네트워크 간 전환이 있었는지, 시스템 절전으로 연결 상태가 달라졌는지 확인하세요. NAT 매핑 만료가 의심되면 원래 설정에 따라 PersistentKeepalive 값을 점검합니다. 예: 25초. Settings → On Demand에 관련 트리거 조건이 설정되어 있는지도 확인하세요. Keepalive는 주기적인 통신을 늘릴 뿐, 네트워크 전환 후 실제로 다시 테스트하는 일을 대신하지 않습니다.

문제 해결 자료를 전달할 때는 실패 시각, 네트워크 유형, 대상 주소 유형, Global Routing 값, 핸드셰이크 발생 여부를 설명할 수 있습니다. 단, PrivateKey, PresharedKey, 전체 구독 주소는 가려야 합니다. 여러 설정을 연이어 바꾸기보다 한 번에 하나의 필드만 변경해 기록하면 원인을 찾기 쉽습니다.