WireGuard 설정과 이용 중인 서비스가 있고 매개변수를 직접 확인하려는 사용자를 위한 글입니다. 먼저 클라이언트와 원격 피어의 신원을 구분하고, 주소, 엔드포인트, 키, MTU, DNS 순서로 확인하세요. 마지막으로 정해진 테스트 순서에 따라 핸드셰이크 실패, DNS 조회 실패, 규칙에 따른 라우팅 문제를 구별합니다. 글에 나오는 주소는 필드 설명을 위한 예시이며, 실제로 연결할 수 있는 서비스 설정이 아닙니다.
1. Home에서 WireGuard 항목 추가
Shadowrocket의 WireGuard 항목에는 서로 맞물리는 매개변수가 필요합니다. 원격 주소와 포트만으로는 연결할 수 없습니다. 원격 피어에는 이 기기의 Private Key에 대응하는 공개 키가 등록되어 있어야 하며, 클라이언트에 터널 주소도 할당되어야 합니다. 이 글은 사용자가 본인에게 제공된 적법한 설정을 이미 보유한 경우를 전제로 하며, 서비스 출처를 선택하는 방법은 다루지 않습니다.
Home 오른쪽 위의 “+”를 눌러 Add Server로 이동한 다음, Type을 WireGuard로 설정하고 해당 유형에 표시되는 필드를 확인합니다. 양식에 서버 주소, 포트, 키가 각각 별도 필드로 표시될 수 있습니다. 아래에서는 먼저 엔드포인트를 설명한 뒤 키, 터널 주소, 고급 매개변수를 살펴봅니다. 표시되는 필드와 선택 항목은 현재 앱 화면을 기준으로 확인하세요. 다른 프로토콜의 Password나 UUID를 WireGuard 키 필드에 입력하면 안 됩니다.
-
설정 준비
본인 설정 기록에서 Interface와 Peer 두 부분을 확인하고 원본 사본을 보관하세요. PrivateKey는 이 기기에 해당하며, Peer의 PublicKey는 원격 피어에 해당합니다. 두 키를 서로 바꾸어 입력하지 마세요.
-
유형 선택
Home → “+” → Add Server → Type → WireGuard로 이동합니다. 먼저 유형을 확인한 다음 주소와 키를 입력해 앞서 선택한 다른 프로토콜의 필드 의미를 그대로 적용하지 않도록 합니다.
-
항목별 입력
본인 설정에 따라 서버 주소, 포트, Private Key, 원격 Public Key, 터널 주소를 입력합니다. MTU, DNS, 선택적 키도 우선 원래 설정값을 사용하세요.
-
저장 후 테스트
저장한 뒤 Home으로 돌아가 해당 항목을 선택하고 연결 스위치를 켭니다. 처음 사용하는 경우 시스템 안내에 따라 VPN 구성을 허용한 뒤 Connectivity Test로 연결을 확인하세요.
2. Endpoint: 원격 주소와 포트 구분
Endpoint는 공용 네트워크에서 도달할 수 있는 WireGuard 피어의 위치로, 호스트 이름 또는 IP 주소와 UDP 포트로 구성됩니다. 원본 설정에는 두 값이 vpn.example.com:51820처럼 한 줄로 적혀 있을 수 있습니다. Add Server에 Address와 Port가 따로 표시된다면 호스트 부분은 주소 필드에, 51820은 포트 필드에 입력하세요. 전체 문자열을 두 필드에 반복해서 붙여 넣으면 안 됩니다.
| 원본 텍스트 예시 | 호스트 부분 | 포트 부분 |
|---|---|---|
vpn.example.com:51820 | vpn.example.com | 51820 |
192.0.2.10:51820 | 192.0.2.10 | 51820 |
[2001:db8::10]:51820 | 2001:db8::10 | 51820 |
위 표의 도메인과 주소는 문서용 예시이며 실제 연결에 사용할 수 없습니다. IPv6 주소를 한 줄로 입력할 때는 대괄호로 주소와 포트를 구분합니다. 필드가 분리되어 있다면 해당 주소 필드의 입력 형식을 따르세요. 호스트 필드 앞에 https://를 붙이거나 웹페이지 경로를 추가하지 마세요.
51820은 흔히 쓰이는 예시 포트일 뿐 모든 WireGuard 서비스가 이 포트를 사용하는 것은 아닙니다. 포트는 본인 설정에 지정된 값을 사용하세요. WireGuard는 UDP를 사용하므로 특정 주소의 TCP 포트에 접속할 수 있더라도 같은 번호의 UDP 포트가 작동한다는 뜻은 아닙니다. 도메인 조회 실패, 잘못된 포트, 현재 네트워크의 UDP 제한은 응답이 계속 없는 원인이 될 수 있지만, 이 증상만으로 어떤 항목이 잘못되었는지 판단할 수는 없습니다.
3. Private Key, Public Key와 선택적 키
Private Key는 이 기기의 개인 키입니다. 이 키로 이 기기의 공개 키가 결정되며, 원격 피어에는 해당 공개 키가 미리 등록되어 있어야 합니다. 원격 설정 항목의 Public Key는 일반적으로 서버의 공개 키를 가리키며, Private Key에서 파생한 본인 공개 키를 다시 입력하는 곳이 아닙니다. 두 값 모두 긴 Base64 문자열로 보일 수 있으므로 겉모양만으로 어느 쪽의 키인지 판단하지 마세요.
정리: 키의 소유자를 먼저 확인하고 재생성 여부를 판단하세요
원본 설정을 기준으로 이 기기의 Private Key와 원격 Public Key를 각각 확인하세요. 문제를 해결하려고 곧바로 새 개인 키를 만들지 마세요. 개인 키를 바꾸면 원격 피어에 등록된 클라이언트 공개 키도 함께 변경해야 합니다. 그렇지 않으면 엔드포인트가 올바르더라도 인증이 완료되지 않습니다.
- Private Key: 복사할 때 필드 이름, 따옴표, 줄바꿈, 앞뒤 공백이 포함되지 않도록 하세요. 실제 개인 키를 공개 문의, 스크린샷 또는 테스트 문서에 올리지 마세요.
- Public Key: 본인 서비스 설정에서 Peer에 해당하는 공개 키를 사용하세요. 서버 도메인, 계정 비밀번호, 구독 토큰이 아닙니다.
- Pre-shared Key: 설정과 현재 화면에 이 선택 항목이 있다면 양쪽에서 같은 값을 사용해야 합니다. 원본 설정에 없다면 임의의 값을 추가하지 마세요.
길이가 맞는다는 것은 문자열 형식이 적절해 보인다는 뜻일 뿐, 키가 원격 피어와 일치한다는 보장은 아닙니다. 공개 키 입력 오류, 개인 키 불일치, Pre-shared Key 불일치는 모두 정상적인 통신이 이루어지지 않는 원인이 될 수 있습니다. 모든 항목을 원본 기록과 대조하세요. 연결 실패를 모두 포트 문제로 단정하지 마세요.
4. 터널 주소: Address와 Endpoint는 다릅니다
‘주소’라는 뜻을 가진 필드라도 역할은 서로 다를 수 있습니다. Endpoint의 주소는 공용 네트워크에서 원격 피어를 찾는 데 쓰이고, Interface의 Address는 이 기기가 터널 안에서 사용할 주소입니다. 원본 설정에 10.66.0.2/32가 있다면 이는 클라이언트의 내부 주소와 접두사 길이를 나타냅니다. 공용 서버의 호스트 필드에 입력하면 안 됩니다.
| 설정 항목 | 예시 텍스트 | 입력 기준 |
|---|---|---|
| Endpoint | vpn.example.com:51820 | 원격 접속 지점입니다. 화면에 따라 호스트와 포트를 나누어 입력합니다. |
| Interface Address | 10.66.0.2/32 | 이 기기의 터널 주소입니다. 할당된 주소와 필요한 접두사 길이를 그대로 사용합니다. |
| IPv6 Address | fd00:66::2/128 | 본인 설정에 IPv6가 할당된 경우에만 입력합니다. |
| AllowedIPs | 0.0.0.0/0, ::/0 | WireGuard 주소 범위 설정이며 DNS나 키가 아닙니다. |
위 예시를 보고 터널 주소를 임의로 선택하지 마세요. 같은 원격 피어를 사용하는 클라이언트끼리는 주소가 겹치지 않아야 합니다. 다른 기기의 신원 정보와 주소를 통째로 재사용하면 통신이 번갈아 끊길 수 있습니다. 여러 기기를 함께 사용하려면 서비스에서 기기별로 할당한 별도 설정을 사용하세요.
AllowedIPs를 Shadowrocket의 전체 라우팅 모드와 같은 의미로 보면 안 됩니다. WireGuard에서 피어의 주소 범위를 처리하는 데 쓰이며, 앱의 연결이 해당 서버를 거칠지는 Global Routing과 Config의 규칙에도 달려 있습니다. 원본 설정에 이 항목이 있지만 현재 편집 화면에 같은 이름의 필드가 없다면 Address나 DNS 필드에 붙여 넣지 마세요. 현재 지원되는 가져오기 방법과 설정 안내를 먼저 확인하세요.
5. MTU와 DNS: 연결 후에도 문제가 생길 때 확인할 항목
MTU는 터널 인터페이스가 처리할 데이터 패킷의 크기를 제한합니다. 값이 너무 크면 바깥쪽 캡슐화 과정에서 경로가 감당할 수 있는 크기를 초과할 수 있습니다. 경로상의 단편화 처리나 오류 피드백이 제대로 이루어지지 않으면 작은 요청은 성공하지만 큰 요청은 멈추는 현상이 나타날 수 있습니다. 이는 문제를 좁히는 단서일 뿐, 웹페이지가 느리게 열린다는 이유만으로 원인을 단정할 수는 없습니다.
- 먼저 원래 값 유지: 본인 설정에 MTU가 명시되어 있다면 우선 해당 값을 사용하세요. 지정된 값이 없다면 앱의 기본 동작을 유지하고, 처음부터 여러 고급 매개변수를 동시에 바꾸지 마세요.
- 한 번에 하나씩 시험: 예를 들어 원래 값이
1420이고 큰 패킷 관련 문제가 확인되었다면, 같은 요청을1380으로 임시 변경해 다시 테스트할 수 있습니다. 이 값은 문제 확인을 위한 예시이지, 모든 환경에 가장 적합한 값은 아닙니다. - 결과 기록: 요청 성공 여부, 시간 초과 여부, 사용한 네트워크를 각각 기록하세요. 개선이 안정적으로 나타나지 않으면 원래 값으로 되돌리고 DNS 조회, 라우팅, 원격 상태를 계속 확인하세요.
DNS는 도메인을 주소로 변환하며 키나 포트 오류를 해결하지는 않습니다. 원본 WireGuard 설정의 DNS는 터널에서 사용할 DNS 서버를 뜻하는 경우가 많습니다. Shadowrocket의 실제 DNS 조회 방식은 Config의 DNS 설정과 관련 라우팅에도 영향을 받습니다. 따라서 서버 항목에 DNS 주소를 하나 입력했다고 모든 도메인 조회가 반드시 같은 경로를 따른다고 볼 수는 없습니다.
내부 DNS 주소도 해당 네트워크 경로를 통해 접속할 수 있어야 합니다. “주소로 테스트하면 응답하지만 도메인 요청은 실패”하는 경우 조회 결과와 DNS 연결 가능성을 먼저 확인할 수 있습니다. 다만 웹사이트는 올바른 도메인 및 TLS 정보에 의존할 수 있습니다. 브라우저에서 특정 IP에 직접 접속한 결과를 도메인 전체 테스트 대신 사용하지 마세요.
6. Global Routing: 프로토콜 문제와 규칙 문제 구분
WireGuard 항목을 저장한 뒤 Home에서 해당 서버를 선택해야 합니다. 연결 스위치를 켜면 시스템에서 해당 VPN 구성을 활성화하지만, 원격 피어가 응답했다는 뜻은 아닙니다. 테스트할 때는 트래픽이 실제로 해당 항목을 통과하는지 먼저 확인하세요. 그렇지 않으면 “테스트는 통과했지만 실제로는 Direct로 연결된” 상황을 오해할 수 있습니다.
Config
권장현재 설정 파일의 규칙에 따라 연결을 처리합니다. 테스트 대상에 적용되는 정책이 확인하려는 WireGuard 항목을 가리키는지 확인하세요. DIRECT에 해당하는 요청으로는 해당 항목이 작동한다고 판단할 수 없습니다.
적합한 경우: 매개변수 확인을 마친 뒤 기존 규칙에 따라 평소처럼 트래픽을 분기할 때.
Proxy
가로채는 연결을 프록시 방식으로 처리해 규칙 분기가 테스트에 미치는 영향을 일시적으로 줄일 수 있습니다. 선택한 서버가 맞는지 확인해야 하며, 이 모드가 시스템의 모든 트래픽 경계를 우회한다고 이해해서는 안 됩니다.
적합한 경우: Config 규칙이 테스트 경로에 영향을 주는지 잠시 확인할 때.
Direct
연결을 직접 연결 방식으로 처리합니다. 현재 기본 네트워크를 확인하는 데 유용하지만, 직접 연결에 성공해도 WireGuard의 키, 포트 또는 터널 주소가 올바르다는 뜻은 아닙니다.
적합한 경우: 프록시를 거치지 않는 기본 네트워크의 상태를 비교할 때.
평소 Scene을 사용한다면 현재 선택한 장면에서 실제로 사용하는 서버와 규칙을 먼저 확인한 뒤 테스트 결과를 해석하세요. 점검이 끝나면 원래 모드로 복원합니다. Settings → On Demand에서는 테스트 중 연결 상태가 바뀌도록 하는 조건이 작동하는지 확인하세요. On Demand는 WireGuard 인증을 대신하거나 잘못된 매개변수를 수정하지 않습니다.
Config에서 DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 대역을, GEOIP는 IP의 지리적 위치를 기준으로 일치 항목을 찾습니다. FINAL은 앞선 규칙에 해당하지 않은 연결을 처리합니다. 규칙은 순서에 따라 라우팅에 영향을 주므로 Home 상단의 스위치만 보고 프로토콜 상태를 판단하지 말고 실제로 적용된 정책을 함께 확인하세요.
7. 증상별로 확인하고 여러 필드를 한꺼번에 바꾸지 마세요
안정적인 네트워크에서 기준 상태를 저장한 뒤 Connectivity Test와 실제 서비스 요청으로 교차 확인하세요. 한 번 측정한 지연 시간만으로 모든 대상에 연결할 수 있다고 판단할 수 없으며, 테스트 실패가 곧 키 오류를 의미하지도 않습니다. 아래 표는 확인 순서를 정하기 위한 것으로, 한 가지 증상만 보고 원인을 단정하는 용도가 아닙니다.
| 관찰된 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| 연결을 켠 뒤 요청이 계속 시간 초과됨 | Endpoint, UDP 연결 가능 여부, 양쪽 키 | 원본 설정과 대조해 하나씩 확인하고 Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트합니다. |
| 도메인 요청 실패 | DNS 결과, 조회 경로, DNS 연결 가능 여부 | Endpoint 도메인 조회와 대상 도메인 조회를 구분하고 현재 Config를 확인합니다. |
| 작은 요청은 성공하지만 큰 요청은 멈춤 | 경로 MTU, 패킷 손실, 원격 피어 부하 | 대상과 네트워크를 그대로 둔 채 MTU만 바꾸어 비교 테스트합니다. 결과를 기록한 뒤 원래 값으로 되돌리거나 효과가 확인된 값을 유지하세요. |
| 일부 대상에서만 문제 발생 | 규칙 적용 결과, IPv4 및 IPv6 경로 | 같은 서버를 사용 중인지 확인하고 키를 바로 새로 만들지 마세요. |
| 네트워크를 바꾼 뒤에만 문제 발생 | 새 네트워크의 UDP, 도메인 조회, 연결 상태 | 연결을 다시 설정한 뒤 테스트하고 두 네트워크의 차이를 비교합니다. |
해당 항목이 사용자가 기존에 이용하던 구독에서 가져온 것이라면 구독을 업데이트할 때 직접 수정한 내용이 덮어써질 수 있습니다. 수정 전에 원래 매개변수를 보관하고 테스트 항목과 구독 관리 항목을 구분할 수 있도록 메모를 남기세요. 이용 중인 서비스 제공자에게 문의할 때는 테스트한 네트워크, 증상, 확인한 필드 이름을 전달하면 됩니다. 실제 Private Key, Pre-shared Key, 전체 구독 링크는 공개 기록에 올리지 마세요.
최종 확인 순서는 원격 접속 지점 연결 가능 여부, 키 소유자 일치 여부, 터널 주소 일치 여부, DNS 조회 경로 사용 가능 여부, 대상 트래픽이 실제로 해당 서버를 통과하는지입니다. 이 기본 항목을 모두 확인한 뒤 MTU 조정을 검토해야 고급 매개변수로 기초 입력 오류를 가리는 일을 막을 수 있습니다.