목차
프록시 노드를 직접 구축해 본 사람이라면 누구나 이런 고민을 해봤을 겁니다:
VPS를 샀는데 어떤 프로토콜을 깔아야 할까?
ChatGPT에 접속하면 왜 항상 국가 제한이 뜰까?
도메인은 꼭 사야 하나?
내 IP는 왜 걸핏하면 막힐까?
저도 이 과정을 전부 겪었습니다. 포럼을 뒤지고 튜토리얼을 따라 하며 갖은 삽질을 한 끝에야 VLESS, Reality, Hysteria2, WARP가 각각 어떤 역할을 하는지 완전히 이해할 수 있었어요.
원리를 이해하고 나니 이런 생각이 들었습니다: 이렇게 정형화된 작업이라면 전부 자동화할 수 있지 않을까?
그래서 전체 구축 과정을 Claude의 Skill로 패키징했습니다. 이제는 새 VPS를 띄우고 IP만 던져주면, 명령어 한 줄 직접 칠 필요 없이 구독 링크까지 깔끔하게 뽑아줍니다.
이번 글에서는 각 기술이 실제로 무엇을 해결해 주는지 명쾌하게 설명해 드리고, 제가 구축한 아키텍처와 워크플로를 공유해 드릴게요.
VLESS + Reality: 현재 가장 강력한 조합
VLESS는 Xray의 핵심 프로토콜입니다. 이전의 VMess와 비교하면 자체적인 암호화 오버헤드를 걷어내고 기본 TLS에 암호화를 온전히 맡깁니다. 덕분에 가볍고 빠르며 CPU 소모가 적습니다.
하지만 VLESS 단독으로는 도메인을 구매하고 SSL 인증서를 발급받아야 합니다. 인증서가 갱신되지 않거나 도메인이 타깃이 되면 노드가 바로 무력화되죠.
Reality는 바로 이 지점을 완전히 해결합니다.
도메인을 살 필요도, 인증서를 발급받을 필요도 없습니다. Reality는 정상적인 대형 웹사이트(예: Apple, Microsoft, Yahoo 등)의 TLS 인증서를 ‘빌려서’ 위장합니다.
외부 감시자가 볼 때 여러분의 트래픽은 그저 평범하게 Microsoft 웹사이트를 브라우징하는 완벽한 정상 TLS 핸드셰이크로 보입니다. 서버 측에서는 사전 공유된 비대칭 키를 통해 진짜 내 클라이언트인지 판별합니다. 검증에 통과하면 프록시 터널로 연결해 주고, 키가 없는 외부 탐색자가 접속하면 진짜 Microsoft 사이트로 트래픽을 그대로 포워딩(Fallback)해 버립니다.
자체 도메인이 없으니 인증서 만료나 도메인 차단을 걱정할 필요가 없고, 현존하는 가장 은밀하고 안정적인 메인 회선이 됩니다.
Hysteria2: 패킷 손실이 심한 환경을 뚫는 깡패
VLESS가 정체를 숨기는 은신술이라면, Hysteria2는 속도를 뚫어내는 돌파구입니다.
국제 회선은 저녁 피크 시간대가 되면 패킷 손실률이 10~20%까지 치솟곤 합니다. 전통적인 TCP 기반 프로토콜(VLESS 포함)은 패킷 손실이 감지되면 ’네트워크 정체’로 판단해 스스로 전송 속도를 반토막 냅니다. 손실이 계속되면 속도는 바닥을 치게 되죠.
Hysteria2는 완전히 다른 방식을 취합니다. 바로 UDP 기반의 QUIC 프로토콜을 개조한 것입니다.
여기에 Brutal이라는 공격적인 혼잡 제어 알고리즘을 얹었습니다. 대역폭을 100Mbps로 지정하면 패킷이 누락되든 말든 신경 쓰지 않고 100Mbps 속도로 데이터를 밀어 넣으며 손실된 패킷만 즉시 재전송합니다. 속도를 줄이지 않고 그냥 힘으로 밀어붙이는 방식이죠.
다만 약점도 있습니다. 일부 통신사나 네트워크 환경에서는 UDP 트래픽 전체를 제한(QoS)하거나 차단하기도 합니다. 그런 환경에서는 오히려 TCP보다 느려질 수 있어요. 따라서 저는 Hysteria2를 평소에는 예비용 백업 회선으로 두고, 메인 회선이 버벅댈 때 스위칭해서 사용합니다.
WARP: 데이터센터 IP를 가정용 IP처럼 세탁하기
WARP는 Cloudflare의 공식 1.1.1.1 서비스 백엔드에 들어가는 터널링 기술입니다. 보통은 스마트폰이나 PC에 깔아서 쓰지만, 저는 이를 ’서버 내부의 아웃바운드 터널’로 설치합니다.
Xray는 유연한 라우팅 규칙을 제공합니다:
- Inbound: 내 기기에서 서버로 들어오는 통로
- Outbound: 서버에서 외부 인터넷으로 나가는 출구
일반적인 노드는 서버 자체의 공인 IP로 인터넷에 나갑니다. 문제는 VPS 호스팅 업체의 IP 대역은 데이터센터(IDC) IP로 널리 알려져 있다는 점입니다.
OpenAI, Claude 같은 주요 AI 서비스들은 데이터센터 IP의 접속을 칼같이 차단합니다. 노드는 정상 연결되었는데 웹페이지에서는 ’현재 국가/지역에서는 서비스를 이용할 수 없습니다’라는 에러가 뜨는 이유가 바로 이 때문입니다.
이때 Xray의 라우팅 규칙을 설정해 AI 도메인으로 가는 트래픽만 WARP 아웃바운드로 빼냅니다. Cloudflare의 방대한 글로벌 Anycast 네트워크를 거쳐 나가기 때문에, 대상 사이트는 이를 일반 가정용/개인 유저의 접속으로 인식해 차단을 우회할 수 있습니다.
구독(Subscription) 시스템 구축
노드가 여러 개면 링크 관리도 번거로워집니다.
노드 설정 정보(프로토콜, 주소, 포트, UUID, 공개키 등)를 담은 링크들을 모아서 Base64로 인코딩한 URL을 ’구독 링크’라고 합니다. 클라이언트는 이 URL을 주기적으로 조회해 최신 노드 목록을 자동으로 동기화합니다.
저는 VPS 서버 안에 아주 가벼운 구독 서비스 데몬을 직접 띄워두었습니다. 서버 설정을 바꾸더라도 클라이언트에서 ‘구독 갱신’ 한 번만 누르면 스마트폰과 노트북 모두에 변경 사항이 즉시 반영됩니다. 구독 URL은 모든 노드에 접근할 수 있는 열쇠이므로, 무작위 난수 문자열을 섞어 비공개로 관리해야 합니다.
현재 저의 운영 아키텍처
- 서버: DigitalOcean 최저 사양 (월 4달러 수준이면 노드 운영에 차고 넘칩니다)
- 코어: Xray
- 메인 회선: VLESS + Reality (직접 아웃바운드)
- AI 전용 분기: VLESS + Reality -> WARP 아웃바운드
- 백업 회선: Hysteria2
- 배포: 자체 호스팅 구독 서버 연동
처음 구축할 때는 튜토리얼을 보며 한 줄 한 줄 손으로 쳤습니다. 패키지 설치, 키 쌍 생성, JSON 설정 파일 작성, 방화벽 포트 오픈, 구독 링크 생성… 오타 하나라도 나면 로그를 몇 시간씩 뒤져야 했죠.
문득 그런 생각이 들었습니다. ‘이미 AI를 다루고 있는데, 사람이 왜 터미널에서 이런 반복 작업을 일일이 치고 있어야 하지?’
그래서 전체 구축 파이프라인을 4단계(초기 배포, 상태 진단, 장애 복구, 구독 마이그레이션)로 묶어 완벽한 Claude Skill로 제작했습니다.
지금은 새 서버가 생기면 Claude에게 IP와 접속 권한만 넘겨줍니다. 그러면 알아서 프로토콜을 깔고, 키를 생성하고, 방화벽을 설정한 뒤 마지막에 완성된 구독 URL만 제게 건네줍니다. 문제가 생겼을 때도 진단 명령 한 번이면 어느 포트가 막혔는지, 왜 연결이 안 되는지 즉시 짚어냅니다.
직접 써보며 다듬은 안전한 배포용 버전을 준비하고 있어요. 배포 준비가 끝나면 공유해 드릴게요. 혼자 개인용으로만 안전하게 사용하시고, 외부에 남발하거나 상업적으로 판매하지는 마세요.
여러분은 시중의 완제품 VPN을 쓰시나요, 아니면 직접 구축해 쓰시나요? 가장 골치 아팠던 문제는 무엇이었나요?
