Happ Proxy: Happ용 프록시 — 켜고 설정하는 방법

Happ Proxy란 무엇이고 프록시 모드는 어떻게 작동하는가

Happ Proxy는 앱의 트래픽을 선택한 서버까지 암호화된 터널로 감싸는 Happ 클라이언트의 전송 계층입니다. '모든 트래픽을 하나의 VPN으로'라는 고전적인 방식과 달리, Happ용 프록시는 지점 단위로 작동합니다. 기기에 로컬 프록시 엔드포인트를 띄우고, 정해진 규칙에 따라 어떤 연결을 서버로 보내고 어떤 연결을 직접 연결로 둘지 결정합니다. 바로 이 선택성이 Happ을 단순한 '연결하기' 버튼이 아니라 설정 도구로 만들어 줍니다.

내부적으로 Happ은 현대적인 전송 방식인 VLESS, VMess, Trojan, Shadowsocks를 지원하며, 이들은 구독 링크를 통해 앱으로 전달됩니다. 클라이언트는 구독을 분석해 노드의 매개변수(주소, 포트, 암호화 방식, TLS/Reality, SNI)를 추출하고 이를 프로필로 대기시켜 둡니다. 재설치 없이 프로필 간에 전환할 수 있으며, 바뀌는 것은 활성 경로뿐입니다.

프록시 모드의 실질적 의미는 안정성과 제어에 있습니다. 은행 앱을 터널 밖으로 보낼지, 스트리밍은 원하는 지역의 서버를 통해 보낼지 직접 결정합니다. 이 논리 위에 아래에서 설명할 예외 목록과 split tunneling이 얹히며, 특정 작업에 맞는 서버 선택도 함께 이루어집니다.

Happ용 프록시 켜기: 단계별 설정

1단계 — 구독을 추가합니다. Happ을 열고 프로필/구성 섹션으로 이동한 뒤 구독 링크(happ://, vless:// 형식 또는 구독용 https 링크)를 붙여넣습니다. 클라이언트가 사용 가능한 노드 목록을 불러옵니다. 링크는 하나인데 노드가 여러 개라면 정상입니다. 구독은 보통 서버 풀을 포함합니다.

2단계 — 노드와 프로토콜을 선택합니다. 처음 실행할 때는 지리적으로 가장 가까운 서버를 VLESS + Reality 또는 Trojan으로 고르세요. 이들은 불안정한 네트워크에서 연결을 더 잘 유지합니다. 노드를 눌러 활성화하고 지연(ping) 테스트를 실행하세요. 초록색 체크 표시가 아니라 실제 응답 속도를 보여줍니다.

3단계 — 터널을 활성화합니다. 연결 버튼을 누릅니다. Android에서는 VPN 인터페이스 생성 권한을 시스템이 요청하는데, 이는 프록시가 트래픽을 가로채는 정상적인 메커니즘입니다. Windows에서는 완전한 TUN 모드를 위해 시스템 네트워크 어댑터를 띄우는 Happ Utility를 사용합니다(/proxy-utility/ 섹션 참조).

4단계 — 경로를 확인합니다. IP 확인 서비스를 아무거나 열어 주소가 서버 주소로 바뀌었는지 확인하세요. IP가 그대로라면 트래픽이 터널을 우회하는 것이므로 라우팅 모드와 앱 권한을 점검해야 합니다.

라우팅과 예외 목록 (split tunneling)

Happ의 예외 목록은 어떤 도메인과 앱이 터널을 우회하고 어떤 것이 서버를 통과할지 결정합니다. 이것이 세밀한 설정의 핵심입니다. 잘 구성된 목록은 서버 부하를 줄이고 로컬 서비스를 빠르게 하며 불필요한 전환을 없앱니다. 목록은 두 가지 논리로 다룰 수 있습니다 — '기본은 프록시를 통해, 예외는 직접 연결' 또는 그 반대입니다.

앱별 split tunneling은 Android와 Windows의 TUN 모드에서 사용할 수 있습니다. 터널을 켜거나 끌 특정 앱을 표시하면 됩니다. 전형적인 시나리오는 은행, 로컬 뱅킹, 지역 변경에 민감한 앱을 터널에서 빼고, 메신저와 미디어는 서버에 남겨 두는 것입니다. 모드별 자세한 분석은 /split-tunneling/ 페이지에 있습니다.

도메인 라우팅에는 목록 기반 규칙을 사용합니다. geosite/geoip 세트를 이용하면 하나의 규칙으로 전체 카테고리(예: 로컬 리소스)를 직접 연결로 보내고 나머지는 모두 서버를 통해 보낼 수 있습니다. 완성된 세트로 시작한 뒤 필요에 따라 지점별 예외를 추가하세요. 그래야 목록이 관리 가능한 상태로 유지되며 수백 개의 수동 항목이 뒤섞인 잡동사니가 되지 않습니다.

목록을 수정할 때마다 연결을 재시작하고 실제 도메인에서 결과를 확인하세요. 규칙은 우선순위 순서로 적용됩니다. 더 구체적인 규칙이 일반 규칙보다 위에 있어야 하며, 그렇지 않으면 넓은 규칙이 트래픽을 먼저 가로챕니다.

속도와 연결 안정성 최적화

Happ용 프록시의 속도는 세 가지 요인으로 결정됩니다 — 서버의 근접성과 부하, 선택한 전송 방식, 네트워크 매개변수입니다. 서버부터 시작하세요. 구독의 여러 노드에 대해 ping을 돌려 보고, 가장 '보기 좋은' 것이 아니라 응답이 가장 안정적인 것을 고르세요. 작업에 맞는 노드 선택은 /servers/ 섹션에서 다룹니다.

전송 방식은 패킷 손실에 대한 내성에 영향을 줍니다. 모바일 네트워크나 간섭이 있는 Wi-Fi에서는 UDP 기반 방식(예: QUIC/Reality 위의 연결)이 종종 더 고른 속도를 내고, 엄격한 기업 네트워크에서는 TCP+TLS가 더 잘 유지됩니다. 끊김이 반복되면 프로필에서 프로토콜을 전환해 비교해 보세요.

네트워크 수준의 세밀한 설정은 '요동치는' 속도에 도움이 됩니다. MTU를 낮추면(문제가 있는 회선에서는 1400 부근으로) 단편화가 사라지고, mux/멀티플렉싱을 켜면 다수의 짧은 연결에서 오버헤드가 줄어듭니다. 한 번에 하나의 매개변수만 바꾸고 측정하세요. 그렇지 않으면 무엇이 효과가 있었는지 알 수 없습니다.

Windows에서 TUN 모드의 안정성과 시스템 트래픽의 올바른 가로채기는 Happ Utility가 담당합니다. 항상 최신 상태로 유지하세요. 서드파티 네트워크 필터나 오래된 어댑터 드라이버와의 충돌은 속도 저하의 흔한 원인입니다. 암호화와 연결 보호에 관한 문제는 /security/ 섹션에서 다룹니다.

진단: 프록시가 연결되지 않을 때

연결이 되지 않으면 간단한 것부터 복잡한 것 순으로 진행하세요. 먼저 구독을 갱신하세요. 풀의 노드가 바뀌었을 수 있고 클라이언트가 오래된 주소를 붙잡고 있을 수 있습니다. '구독 갱신'을 한 번 누르면 프로필을 새로 만들지 않고도 최신 매개변수를 불러옵니다.

시스템 시간과 시간대를 확인하세요. TLS/Reality 전송 방식은 시계 불일치에 민감합니다. 몇 분의 차이만으로도 핸드셰이크가 깨지며, 겉보기에는 '서버가 응답하지 않는' 것처럼 보입니다. 시간 자동 동기화를 켜세요.

노드와 프로토콜을 바꿔 보세요. 한 서버는 응답이 없는데 같은 구독의 인접 서버는 작동한다면 문제는 클라이언트가 아니라 노드 쪽입니다. 모두 응답이 없다면 대개 통신사 네트워크의 문제입니다. 다른 전송 방식, SNI 변경, 또는 확인을 위해 모바일 인터넷을 통한 연결을 시도해 보세요. 문제 해결에 관한 상세한 체크리스트는 지원 섹션에 정리되어 있습니다.

마지막으로 라우팅과 예외 목록을 확인하세요. 규칙의 오류나 지나치게 넓은 예외는 모든 트래픽을 터널 밖으로 이끌어 '프록시가 작동하지 않는다'는 착각을 만들 수 있습니다. 사용자 규칙을 일시적으로 끄고 기본 연결이 살아 있는지 확인한 뒤 규칙을 하나씩 되돌리세요.