세 가지를 나눠서 보기: 계정, 구독 링크, 클라이언트
연결이 안 되거나, 자주 끊기거나, 구독이 만료되었다는 메시지가 뜨면 초보자는 보통 「회선 문제」라고 생각합니다. 하지만 실제로 더 흔한 원인은 계정, 구독 링크, 클라이언트 중 하나에 문제가 생긴 경우입니다. 이 초보자 보안 가이드는 설정을 어떻게 조정할지보다 먼저 세 가지의 경계를 분명히 합니다. 누가 로그인 권한을 갖고, 누가 연결 권한을 가지며, 각각을 잃었을 때 어떤 순서로 대처해야 하는지 정리합니다.
| 항목 | 무엇인가 | 통제를 벗어났을 때의 영향 | 대응 방법 |
|---|---|---|---|
| 계정(사용자 이름 + 비밀번호) | 사용자 패널 로그인 자격 증명 | 타인이 주문 정보를 확인하고 구독 링크를 재설정할 수 있음 | 비밀번호 변경, 다른 사이트와 같은 비밀번호를 썼다면 함께 변경 |
| 구독 링크 | 클라이언트에서 가져오면 회선 설정을 자동으로 불러오는 주소 | 계정 없이도 가져와서 회선을 사용할 수 있음 | 패널에서 구독을 재설정하면 기존 링크가 즉시 무효화됨 |
| 클라이언트 설정 | 기기에 저장된 노드 정보와 분할 라우팅 규칙 | 같은 기기를 쓰는 다른 사용자가 읽을 수 있음 | 설정 제거, 로그아웃, 내보낸 파일 정리 |
세 항목 중 가장 과소평가되는 것은 두 번째입니다. 계정은 적어도 비밀번호가 앞을 막고 있지만, 구독 링크 자체가 자격 증명입니다. 링크를 손에 넣은 사람은 사용자 이름을 몰라도 되고 동의를 구할 필요도 없이, 가져오는 즉시 같은 회선에 연결할 수 있습니다.
어떤 정보를 보내도 되는지는 한 가지로 판단합니다. 그 정보로 연결을 만들 수 있는가입니다. 가능하다면 비밀번호처럼 다루고, 그렇지 않다면 일반 정보로 봅니다.
구독 링크가 계정 자격 증명과 같은 이유
구독 링크는 보통 http 또는 https로 시작해 평범한 주소처럼 보입니다. 하지만 열어 보면 인코딩된 텍스트가 반환되고, 클라이언트가 이를 디코딩하면 서버 주소, 포트, 프로토콜 종류, 암호화 방식, 비밀번호 또는 UUID까지 연결에 필요한 파라미터가 모두 나옵니다. 즉 「어떤 자격으로 어느 서버에 연결하는가」가 이미 링크 안에 전부 적혀 있는 셈입니다.
아래 두 줄은 형식 예시이며, 주소는 문서용 대역인 203.0.113.0/24에서 가져왔고 비밀번호는 데모 값으로, 실제로 연결되는 서버가 아닙니다.
ss://[email protected]:8388#예시노드
trojan://[email protected]:443?sni=example.com#예시노드
프로토콜마다 담고 있는 자격 증명의 형태는 다르지만 공통점이 있습니다. 링크에 바로 연결을 만들 수 있는 필드가 반드시 포함되어야 하며, 그렇지 않으면 클라이언트가 가져오기를 끝낼 수 없습니다. 구독 링크를 재설정하면 즉시 효과가 나타나는 이유도 여기에 있습니다. 서버 쪽에서 자격 증명을 교체하면 기존 링크의 파라미터가 곧바로 무효가 됩니다.
| 프로토콜 | 자격 증명 형태 | 전송 계층 | 설명 |
|---|---|---|---|
| Shadowsocks | 비밀번호 + 암호화 방식 | TCP, UDP 포워딩 별도 설정 가능 | 구조가 단순하고 클라이언트 호환성이 넓음 |
| VMess | UUID | TCP, WebSocket / gRPC 등 전송 계층 조합 가능 | 파라미터가 많아 가져올 때 전송 계층 설정과 함께 맞춰야 함 |
| Trojan | 비밀번호 | TCP, TLS 사용, 포트는 보통 443 | 트래픽 특성이 일반 HTTPS에 가까움 |
| VLESS | UUID | TCP, 주로 XTLS / Reality와 조합 | 구조가 VMess보다 간결하고 암호화는 전송 계층에 맡김 |
| Hysteria2 | 비밀번호 또는 인증 문자열 | QUIC 기반, UDP 사용 | 패킷 손실이 많은 회선을 대상으로 하며 UDP 경로에 의존 |
| TUIC | UUID + 비밀번호(v5) | QUIC 기반, UDP 사용 | Hysteria2와 마찬가지로 QUIC 계열이며 UDP 품질에 영향받음 |
이 표가 말하는 것은 한 가지입니다. 어떤 프로토콜을 쓰든 구독 링크에는 바로 연결을 만들 수 있는 자격 증명이 반드시 들어 있습니다. 링크가 복사되면 연결 권한이 복사되는 것과 같으며, 프로토콜 자체가 얼마나 앞서 있는지와는 관계가 없습니다.
구독 재설정이 즉시 효과를 내는 이유
구독 링크는 서버에서 발급하며, 재설정하면 서버 쪽에서 해당 자격 증명이 교체됩니다. 기존 링크로 다시 설정을 가져오려 해도 서버가 더 이상 인식하지 않으므로, 재설정은 연결 권한을 끊는 가장 빠른 방법입니다. 반면 비밀번호 변경은 사용자 패널 로그인에만 영향을 주며 이미 유출된 구독 링크를 무효화하지는 못합니다. 두 작업의 적용 범위가 다르므로 서로 대신할 수 없습니다.
「링크는 나만 알고 있다」는 생각은 대개 사실이 아닙니다. 구독 링크는 클라이언트에 평문으로 저장되며, 스크린샷, 클립보드 기록, 채팅 내역, 문의 내용에도 쉽게 남습니다. 한 번이라도 전달하면 연결 권한을 그대로 복사해 준 셈입니다.
공용 Wi-Fi에서 실제 위험은 어디에 있는가
공용 Wi-Fi의 위험은 「신호가 가로채진다」는 막연한 표현에 있지 않고, 하나씩 확인할 수 있는 몇 가지 구체적인 지점에 있습니다. 아래에서 발생 방식별로 나누어 정리하고, 암호화 터널이 어디까지 막아 주는지도 함께 표시했습니다.
| 위험 지점 | 실제 발생 방식 | 터널 완화 여부 |
|---|---|---|
| 같은 대역에서의 스니핑 | 평문 HTTP 요청이 같은 네트워크의 기기에서 읽힐 수 있음 | 완화됨: 트래픽이 터널로 들어가면 읽을 수 없음 |
| 위조된 포털 로그인 페이지 | 가짜 페이지가 로그인 창에 입력한 계정과 비밀번호를 수집 | 완화되지 않음: 로그인이 터널 수립 전에 이루어짐 |
| 도메인 조회 결과 변조 | 조회 결과가 바뀌어 겉모습이 같은 위조 사이트로 연결 | 조회가 터널을 통과하는지에 따라 다르며 별도 확인 필요 |
| 이름이 같은 핫스팟 | 기기가 이름이 같은 위조 핫스팟에 자동 연결 | 완화되지 않음: 시스템 설정에서 자동 연결을 꺼야 함 |
표에서 두 줄은 터널로 해결할 수 없습니다. 캡티브 포털은 웹페이지에서 먼저 로그인을 마쳐야 터널을 열어 주므로, 이 단계에서 입력한 내용은 핫스팟 운영자에게 그대로 전달됩니다. 그래서 공용 네트워크에서는 첫째, 시스템의 「알려진 네트워크 자동 연결」을 꺼 두고 둘째, 포털 페이지에서 중요한 계정과 같은 비밀번호를 쓰지 않아야 합니다.
분할 라우팅 규칙이 어떤 트래픽이 실제로 터널을 타는지 결정합니다
클라이언트의 분할 라우팅 규칙(일부 앱에서는 라우팅 규칙이라고 부릅니다)은 어떤 요청이 터널을 타고 어떤 요청이 직접 연결되는지 결정합니다. 기본 규칙은 보통 LAN 주소와 자주 쓰는 국내 사이트를 직접 연결로 두는데, 속도는 빨라지지만 그만큼 해당 트래픽은 터널의 보호를 받지 못합니다. 규칙 내용이 확실하지 않다면 전역 모드로 전환하는 편이 안전하며, 신뢰할 수 있는 네트워크로 돌아온 뒤 규칙 모드로 다시 바꾸고 필요에 따라 조정하면 됩니다.
DNS 유출은 따로 확인해야 할 또 하나의 항목입니다
도메인 조회는 도메인을 주소로 바꾸는 역할을 합니다. 터널이 웹 트래픽만 처리하고 조회 요청은 여전히 로컬 네트워크가 담당하면 DNS 유출이 생깁니다. 어떤 도메인에 접속했는지가 로컬 네트워크에 드러나고, 반환되는 주소도 변조될 수 있습니다. 확인 방법은 간단합니다. 연결한 뒤 아무 DNS 검사 페이지나 열어서 결과에 나오는 리졸버의 지역이 선택한 회선과 일치하는지 보면 됩니다. 일치하지 않는다면 조회가 터널을 통과하지 않은 것이므로, 클라이언트에서 DNS 처리 방식을 터널 경유로 바꾸거나 「유출 방지」 옵션을 켜야 합니다.
플랫폼별 클라이언트 차이
데스크톱 클라이언트(Windows, macOS)는 보통 규칙 모드와 앱별 설정을 온전히 제공해 조정할 수 있는 항목이 가장 많습니다. Android는 앱별로 터널 사용 여부를 선택할 수 있습니다. iOS는 시스템 구조상 규칙이 구성 프로파일에 의해 정해지고 선택 가능한 세분성이 데스크톱보다 거칠어서, 전역 모드와 규칙 모드 중 무엇을 쓸지 더 이른 시점에 정해야 합니다. Linux는 대부분 명령줄 클라이언트라 설정을 직접 관리해야 하므로, 자격 증명이 교체된 뒤 다시 가져오는 일을 잊지 않도록 구독 링크 갱신 주기를 달력에 적어 두는 편이 좋습니다.
상담원이 절대 요구해서는 안 되는 정보
판단 기준은 하나뿐입니다. 상대가 요구하는 것이 문제 원인을 찾는 데 꼭 필요한가입니다. 장애 대응에 실제로 필요한 정보는 생각보다 적으니, 그 범위를 넘어서는 것은 모두 제공하지 않습니다.
- ✅ 제공 가능: 사용자 이름(비밀번호 아님), 주문 번호, 문제 증상, 클라이언트와 시스템 버전, 오류 메시지 전문.
- ✅ 제공 가능: 스크린샷. 다만 보내기 전에 화면에 구독 링크, QR 코드, 노드 정보가 없는지 확인하세요.
- ❌ 제공 불가: 계정 비밀번호. 어떤 경우에도 회선 상태 확인에 비밀번호는 필요하지 않습니다.
- ❌ 제공 불가: 구독 링크 전체. 설정 확인이 필요할 때는 증상만 설명하고 링크는 붙여 넣지 마세요.
- ❌ 제공 불가: 결제 계정의 로그인 정보나 결제 내역에 찍힌 카드 번호 전체.
- ❌ 제공 불가: 신분증 사진. 신원 확인은 회선 장애 대응에 필요한 절차가 아닙니다.
관점을 바꾸면 이 목록은 사칭자를 가려내는 데도 쓸 수 있습니다. 상대가 위에서 ❌로 표시한 내용을 먼저 요구한다면 이유가 아무리 그럴듯해도 일단 멈추고, 직접 연 공식 경로를 통해 대화 상대가 맞는지 다시 확인해야 합니다. 본 서비스는 가입에 사용자 이름과 비밀번호만 필요하고 이메일 주소도 추가 정보도 요구하지 않으며, 이 점 자체가 판단 근거가 될 수 있습니다.
자격 증명 유출이 의심될 때의 대처 순서
구독 링크가 단체 채팅방에 공유된 것을 발견했거나, 낯선 기기에서 계정 로그인 기록이 있거나, 유출 여부가 확실하지 않을 때는 아래 순서대로 처리하세요. 순서는 바꿀 수 없으며, 각 단계 뒤에 이유를 적었습니다.
- 먼저 사용자 패널에서 구독 링크를 재설정하세요. 유출된 자격 증명을 즉시 무효화하는 유일한 방법이며, 연결 권한을 바로 끊을 수 있습니다.
- 다음으로 계정 비밀번호를 변경하세요. 같은 사용자 이름과 비밀번호를 다른 곳에서도 썼다면 그곳도 함께 바꾸세요. 자격 증명을 재사용하면 한 번의 유출이 여러 번의 유출로 번집니다.
- 패널의 주문 및 로그인 정보를 확인하세요. 본인이 하지 않은 변경이 없는지 확인한 뒤 추가 조치가 필요한지 판단하세요.
- 모든 기기에서 기존 설정을 삭제하고 새 구독을 다시 가져오세요. 기존 설정은 저절로 사라지지 않지만 가리키는 자격 증명은 이미 무효이므로, 그대로 두면 연결 실패만 반복됩니다.
- 내보내거나 전달했던 파일을 정리하세요. 채팅 내역에 남은 링크, 클립보드 내용, 설정을 저장해 둔 메모도 포함됩니다.
보안 약속을 검증 가능한 사실로 바꾸기
초보자가 서비스를 고를 때 가장 쉽게 마음이 움직이는 것은 듣기 좋은 단정적인 표현입니다. 이런 말은 검증할 수 있는 의미가 없고 누구나 쓸 수 있습니다. 더 유용한 방법은 상대가 어떤 확인 가능한 사실을 공개하는지 보는 것입니다. 얼마나 많은 국가와 지역을 커버하는지, 회선이 몇 개인지, 환불 기간이 얼마나 되는지, 가입 시 어떤 정보를 제출해야 하는지, 개인정보 처리방침에서 기록 범위를 어떻게 밝히는지입니다.
이 세 가지는 바로 비교할 수 있습니다. 커버 범위는 회선 선택의 폭을, 회선 수는 피크 시간대의 가용성을, 환불 기간은 시행착오 비용을 좌우합니다. 그런데 보안과 직접 관련된 것은 사실 다른 두 가지입니다. 가입할 때 이메일을 제출해야 하는지, 개인정보 처리방침에서 기록 범위를 어떻게 설명하는지입니다. 본 서비스는 가입에 사용자 이름과 비밀번호만 필요하고 이메일 주소를 요구하지 않으며, 개인정보 처리방침에는 브라우징 내용을 기록하지 않는다고 명시되어 있습니다. 이런 표현은 정책 진술로서 검증할 수 있고, 검증할 수 없는 보장으로 포장되지도 않습니다.
처음의 표로 돌아가 봅시다. 계정, 구독 링크, 클라이언트 설정은 각각 하나의 권한에 대응합니다. 세 가지 경계만 기억해 두면 초보 단계에서 피할 수 있는 문제가 대부분 해결됩니다. 기기 수나 회선 선택처럼 사용 방식에 관한 조정은 나중에 천천히 해도 됩니다.