차단 우회 방법

728x90

핵심은 **“무엇을 숨기느냐(어떤 메타정보를 암호화/터널링하느냐)”와 “차단자가 무엇을 차단 대상으로 삼느냐”**입니다.

아래에 단계별로, 그리고 실제로 우회 앱들이 어떻게 동작해서 접속을 가능하게 하는지 정리할게요.

1) 먼저 — 맞는 지적: SNI만 숨겨도 충분하지 않다

DPI는 SNI뿐 아니라 목적지 IP와 DNS 질의도 볼 수 있어요.
따라서 단순히 SNI만 숨겼다고 해도, 차단자가 목적지 IP나 DNS를 이용해 차단하면 여전히 차단당할 수 있습니다.

2) 그래서 HTTPS 우회 앱(또는 VPN 등)은 무엇을 어떻게 숨기나 — 핵심 기법들

A. 터널링 / 프록시(가장 일반적인 방법)

클라이언트 → 암호화된 터널(예: VPN / TLS 터널 / HTTPS 프록시) → 우회 서버(중계) → 원 서버
이 경우 DPI가 보는 건 터널 끝점(우회 서버)의 IP와(및 터널 핸드셰이크 메타데이터) 뿐입니다.
- 즉, 목적지 IP는 우회 서버 IP로 보이고, 실제 접속하려는 원서버 IP는 숨겨집니다.
- DNS 질의도 터널 안으로 넣거나(우회 서버에서 대신 질의) DoH/DoT로 암호화하면 DPI가 못 봅니다.
결과: DPI는 “누가(내 브라우저가) 어떤 원사이트에 가려는지” 식별하지 못하고, 차단하려면 우회 서버 IP를 차단해야 합니다.

B. SNI 암호화(ECH 등)

TLS ClientHello의 SNI 필드를 암호화(Encrypted Client Hello)하여 DPI가 도메인을 읽지 못하게 함.
이 방법은 직접 원 서버로 연결하면서도 SNI 노출을 막는 방식(단, 서버·클라이언트·인프라의 지원이 필요).
단점: DNS나 목적지 IP가 여전히 노출될 수 있고, ECH 지원이 아직 모든 서버/네트워크에 널리 퍼지진 않았음.

C. DNS 암호화(DOH / DOT) 또는 DNS 프록시

평문 DNS를 암호화하거나(DoH/DoT), DNS 질의를 우회 서버로 보냄으로써 DPI가 질의 내용을 못 봅니다.
DNS가 숨겨지면 “어떤 도메인에 접속하려는지”를 DNS로 식별하는 차단은 무력화됩니다.

D. 이전에 쓰이던 기법들 (예: 도메인 프론팅)

도메인 프론팅은 호스트/실제 목적지를 CDN 등의 다른 도메인 뒤에 숨기는 방식이었지만 많은 제공사가 차단했고 더 이상 안정적이지 않습니다.

3) “그럼 도메인을 모르면 어떻게 실제 원서버에 접속하나요?” — 원리 설명

우회 앱이 성공적으로 접속하게 하는 방법은 크게 둘입니다.

방법 1 — 터널(프록시)을 통해 ‘대리 접속’

당신의 기기는 우회 서버(터널 엔드포인트)에 TLS로 연결하고, 우회 서버가 내부에서 실제 목적지(원 서버)에 접속해서 내용을 가져옵니다.
클라이언트는 원서버 도메인을 직접 네트워크에 노출하지 않고도 우회 서버를 통해 콘텐츠를 받을 수 있습니다.
즉, 클라이언트 → (암호화) → 우회서버 → 원서버 흐름.
우회서버는 클라이언트 대신 원서버에 접속하므로, 원서버 도메인을 알 수 없어도 통신 가능.

방법 2 — 직접 연결하지만 SNI를 숨기거나 암호화(ECH)

클라이언트가 원서버에 직접 TLS 연결을 걸되, ClientHello의 SNI를 암호화(ECH)하여 DPI가 도메인을 보지 못하게 함.
이 경우 클라이언트는 여전히 원서버 IP로 직접 접속하므로 DNS·IP 노출 이슈가 남음(DoH로 DNS를 숨기면 좀 더 안전).

4) 남아 있는 위험과 실무적 현실

우회서버 IP 차단: 차단자는 우회 서버(또는 VPN 서버) IP를 차단하면 우회 실패. 그래서 우회 서비스는 IP를 자주 바꾸거나 대규모 인프라를 써야 함.
DNS 노출: 클라이언트가 여전히 평문 DNS를 쓰면, DNS로 접속 도메인을 알 수 있어 차단당함. (DoH/DoT 필요)
TLS 중간복호화: 기관이 클라이언트에 중간자 인증서를 강제 설치하면(회사·학교에서 흔함) TLS를 해제해서 내용까지 검사 가능. 이 경우 우회 어려움↑.
ECH·DoH 보급의 한계: 표준이 확산 중이지만 아직 완전 보편화되진 않았음.

5) 정리 — 질문에 대한 직접적 답

네 — SNI만 숨겨도 충분치 않다. 목적지 IP와 DNS 질의가 그대로면 DPI는 다른 방법으로 차단할 수 있다.
HTTPS 우회 앱이 우회할 수 있는 이유는 보통 (1) 트래픽을 암호화된 터널로 보내 목적지 IP/DNS를 숨기거나, (2) SNI를 암호화(ECH)하거나, (3) 암호화된 DNS를 사용하는 방식 중 하나(또는 조합)를 사용하기 때문입니다.
즉, **클라이언트가 원서버 도메인을 “직접 네트워크에 드러내지 않는” 방법(터널링 등)**을 쓰기 때문에, 차단자가 도메인을 알지 못해 접속이 가능해지는 것입니다.

핵심은 “네트워크 레이어에서 누가(어떤 IP) 누구(어떤 도메인)에 연결하는지”를 누가 아느냐입니다.

아래에서 가능한 방식들을 실전 관점으로 정리해서

— 왜 숨겨도 접속이 가능한지,

그리고 어떤 정보는 반드시 알려져야 하는지(또는 대체 가능한지)

설명할게요.

핵심 요지(먼저 요약)

직접 접속하려면 네트워크는 결국 목적지 IP로 패킷을 라우팅해야 한다. 이 IP는 (평문으로) 라우터/중간 장비에 보인다. → 이 경우 DPI가 IP로 차단 가능.
그래서 대부분의 우회 기법은 **“직접 목적지로 가지 않고, 다른 중계(터널/프록시)로 보내는 방법”**을 쓴다. 즉 클라이언트 → (암호화된 터널) → 중계서버 → 원서버 구조로, DPI가 보는 것은 중계서버의 IP뿐이다. 중계서버가 대신 원서버에 접속하므로 클라이언트 네트워크에는 원서버 정보가 노출되지 않는다.
또 다른 방식은 **SNI만 숨기는 것(ECH 등)**인데, 이건 SNI만 감추고 목적지 IP나 DNS가 드러나면 차단당할 수 있다. 그래서 현실적 우회는 보통 여러 기법의 조합(터널 + 암호화된 DNS + SNI 보호)이다.

방법별로 구체적으로 — “무엇을 숨기고, 누가 대신 해주는가”

1) 터널/프록시 방식(가장 흔함 — VPN, TLS 프록시, HTTPS 프록시, Shadowsocks 등)

동작: 클라이언트가 먼저 우회(중계)서버에 암호화된 연결(TLS/VPN) 을 맺는다.
- 네트워크에 보이는 건 “클라이언트 ↔ 우회서버(암호화된 연결)”와 우회서버의 IP뿐.
우회서버가 대신 원서버에 접속해 데이터를 가져오고, 암호화된 채널로 클라이언트에 전달한다.
결과: DPI는 우회서버 IP만 보므로, 차단하려면 우회서버 IP를 차단해야 함.
장단점: 매우 효과적이지만 차단자는 우회서버 IP를 블록하거나 트래픽 패턴으로 식별하려 시도할 수 있음.

2) HTTP CONNECT / TLS 터널(프록시를 통한 TCP 터널링)

브라우저가 프록시로 TLS 연결을 맺고 CONNECT target:443 요청 → 프록시는 원서버와 연결 후 투명 터널을 만들어 줌.
네트워크 레벨에선 클라이언트→프록시만 보이고, 원서버는 프록시가 대신 연결함.

3) SNI 숨김 / ECH (Encrypted Client Hello)

ClientHello 내부의 SNI(접속 도메인)를 암호화해서 DPI가 도메인을 못 보게 함.
그러나 DNS 질의와 목적지 IP는 여전히 노출될 수 있으므로, 완전한 은닉은 아님.
즉, SNI만 숨기는 것으로는 IP 차단이나 평문 DNS 차단을 막을 수 없다.

4) DNS 암호화 (DoH/DoT) 또는 DNS 프록시

클라이언트의 DNS 질의를 암호화하거나(DoH/DoT) 우회서버로 넣음 → 로컬 네트워크에서 평문 DNS를 통한 도메인 노출을 막음.
하지만 클라이언트가 직접 목적지 IP로 접속하면(터널 없이) IP는 그대로 보인다.

5) 도메인 프론팅 / 호스트 프론팅 (과거 기법 — 현재는 제한됨)

요청의 TLS SNI나 Host를 안전한 대형 도메인으로 설정하고 실제 요청은 다른 백엔드로 라우팅하는 기법. 많은 클라우드/CDN 사업자가 이를 제한하여 더 이상 안정적이지 않음.

질문에 대한 직접적인 답 (요약형)

“목적지 IP·도메인·DNS를 모두 숨기면 원서버를 모른 채 어떻게 접속하냐?”

그건 두 가지 방법 중 하나로 가능해요.
1. 직접 접속하지 않는다(대신 접속해주는 중계서버가 있다).
  - 클라이언트는 중계(우회)서버만 알고 그 서버와 암호화된 연결을 만들어요. 실제 원서버 접속은 중계서버가 수행. 따라서 클라이언트 네트워크에는 원서버 IP/도메인이 드러나지 않습니다.
2. 직접 접속하되 일부 메타정보만 숨긴다(예: SNI 암호화).
  - 이 경우 원서버 IP는 여전히 보이므로, DPI가 IP로 차단하면 막힘. 따라서 SNI 암호화는 DNS·IP 차단을 완전히 회피하려는 목적에는 단독으로 부족합니다.

현실적 한계 & 방어 측면

우회서버(또는 VPN) IP 차단: 차단자는 인기 있는 우회서버 IP를 차단하면 우회 실패. 그래서 우회 서비스는 IP 회전, 대규모 IP 풀 사용 등으로 대응함.
TLS 중간복호화(기업/기관): 조직이 클라이언트에 자체 루트 인증서를 심어 TLS를 복호화하면(중간자), 우회도 어렵다.
트래픽 분석: DPI는 패킷 크기·타이밍·지문(특정 프로토콜의 TLS fingerprint)으로 우회 트래픽을 식별하려 시도할 수 있음.

권장 정리 (요약)

클라이언트가 원서버 정보를 네트워크에 전혀 노출하지 않으려면: 트래픽을 암호화된 터널/프록시로 보내고, DNS도 터널 내로 넣거나 DoH/DoT를 쓰면 된다. 이 경우 DPI가 보는 건 오직 우회서버의 IP뿐.
SNI만 숨기면 충분하지 않다: DNS·IP가 노출되면 차단당함. 현실적인 우회는 여러 기술(터널 + DNS 암호화 + SNI 보호)을 조합한다.
항상 트레이드오프가 있다: 우회서버 IP 차단, 트래픽 분석, 중간자 공격 등으로 완전 무적은 아니다.

핵심은 **“네트워크 패킷을 목적지 IP로 라우팅하려면 반드시 터널의 끝점(endpoint, 즉 IP 주소)이 있어야 한다”**는 점이에요.

그래서 현실적으로는 터널의 끝(종단)이 어디냐가 곧 네트워크에 보이는 대상이 됩니다.

아래에서 차근차근 이유와 설계상의 목적을 설명할게요.

요약(한 문장)

클라이언트가 ‘정체를 숨긴 채’ 원서버에 직접 터널을 열 수는 없다 — 터널을 열려면 해당 터널의 끝점 IP를 알아야 하고, 그 IP가 네트워크에 노출되기 때문에 보통은 “암호화된 터널 → (중계)서버 → 원서버” 구조를 사용해 원서버 정보를 숨깁니다.

왜 그런가? (원리부터)

라우팅의 현실: 패킷은 IP로 간다
- 인터넷은 IP 기반 라우팅이에요. 패킷을 보내려면 목적지 IP가 필요하고, 그 IP는 라우터/ISP에 그대로 보입니다.
- 즉, “클라이언트가 원서버 IP를 모르는 상태에서 직접 원서버로 패킷을 보내는” 건 불가능합니다 — 목적지 IP를 알아야 보내죠.
터널은 반드시 끝점(endpoint)이 있다
- 터널(예: VPN, TLS 터널)은 “내 컴퓨터 ↔ 터널 끝점” 사이에 암호화된 채널을 만든다는 의미.
- 그 끝점의 IP는 네트워크에 노출됩니다. 그래서 누가 보느냐에 따라 그 끝점이 차단 대상이 될 수 있어요.
그래서 중계서버를 끝점으로 쓰는 이유
- 클라이언트는 중계서버 IP만 보이게 하고, 중계서버가 대신 원서버에 연결합니다.
- 이렇게 하면 원서버 IP와 도메인(또는 DNS 질의)을 클라이언트의 네트워크에서는 숨길 수 있습니다.

구체적 비교(그림)

직접 접속(노출 많음) Client --> Internet --> Origin(IP A) (ISP, DPI에 IP A 노출, DNS·SNI도 보일 수 있음) 터널-중계 방식(우회) Client ===encrypted===▶ Proxy (IP P) ▶ Origin (IP A) (네트워크에 보이는 건 Proxy IP P 뿐, DNS/SNI는 터널 내부로 넣을 수 있음)

중계서버가 하는 추가적 ‘실제적’ 역할들

원서버의 IP·도메인 은닉: 차단자로 하여금 원서버를 직접 차단 못 하게 함.
DNS 대리 질의: 클라이언트 대신 DNS를 질의/암호화(DoH)하여 DNS 노출 차단.
캐시/응답 최적화: 캐시로 응답 속도 개선, 부하 감소.
연결 재사용/프록시 풀: 많은 클라이언트의 접속을 효율적으로 관리.
우회·난독화: 우회 서비스는 대량의 IP 풀, 자주 바뀌는 엔드포인트로 차단 회피.

그러면 “직접 터널 → 원서버”는 전혀 불가능한가?

기술적으로는 클라이언트가 원서버의 IP를 알고 있고, DNS를 직접 암호화(DoH)해서 IP로 접속하면 “직접 터널(즉 TLS to origin)”과 사실상 동일한 통신을 할 수 있습니다.
- 다만 이 경우 목적지 IP는 네트워크에 보입니다(그리고 차단 가능).
SNI 암호화(ECH) 같은 기술은 ClientHello의 도메인 노출을 막아주지만, IP·DNS가 남아 있으면 차단당할 수 있음. 그래서 단일 기법으로 완벽 우회가 되지 않는 경우가 많습니다.

보안·정책상의 트레이드오프

장점(중계 사용): 원서버 은닉, DNS 숨김, 차단 회피, 부하 경감 등.
단점(중계 사용): 중계서버를 신뢰해야 함(로그, 개인정보 노출 가능성), 중계서버 IP가 차단되면 서비스 불가.

결론

네트워크 상에서 “무엇이 보이는가” = 터널의 끝점(종단) IP이고, 그 때문에 우회는 대부분 터널을 중계서버로 종단시켜서 원서버 정보를 클라이언트 네트워크에서 숨기는 방식으로 동작합니다.
즉, “클라이언트 → 암호화된 터널 → 원서버”로 보이고 싶어도, 실제로 그 터널의 끝점(IP)을 가리키는 대상이 네트워크에 노출되므로 원서버 은닉을 위해선 중계서버(프록시)가 필요한 경우가 대부분입니다.

“터널(tunnel)”은 네트워킹에서 자주 나오는 개념인데, 핵심은 **“암호화/캡슐화된 통신 경로”**라는 점이에요.

풀어서, 왜 쓰고 어떻게 동작하는지 단계별로 정리할게요.

한 문장 요약

터널은 클라이언트와 ~ 특정 종단(endpoint) 사이에 만든 암호화된 통로입니다.

그 통로 안에 원래 가려던 트래픽(패킷)을 넣어서(캡슐화) 보내면,

중간 네트워크 장비는 통로의 바깥 헤더만 보고 내부 내용이나 최종 목적지는 알기 어렵습니다.

1) 터널의 핵심 요소

종단(endpoint): 터널이 끝나는 지점(예: VPN 서버 IP, SSH 서버 IP). 이 IP는 네트워크에 보인다.
캡슐화(encapsulation): 원래 패킷(예: HTTP 요청)을 터널 프로토콜의 새 패킷 안에 넣음.
암호화(encryption): 캡슐화된 내부 콘텐츠는 암호화되어 중간에서 읽을 수 없음.
탈캡슐화(decapsulation): 터널 종단에서 캡슐을 풀고 내부 패킷을 꺼내 원래 목적지로 전달.

2) 동작 흐름(단순화된 예)

[클라이언트] --(암호화된 터널)--> [터널 종단 서버] --(일반 트래픽)--> [원서버]

클라이언트는 터널 종단 서버 IP로만 패킷을 보냄 → ISP/DPI엔 그 IP만 보임
터널 종단 서버가 내부 패킷을 꺼내 원서버로 요청 → 원서버 응답을 받아 터널로 다시 보냄 → 클라이언트가 복호화

3) 터널의 종류(실무에서 흔히 보는 것)

VPN (OpenVPN, WireGuard, IPSec 등): 기기 전체 트래픽을 터널링
TLS/HTTPS 프록시(예: HTTPS proxy, CONNECT): 브라우저/앱의 특정 연결을 터널로 만듦
SSH 터널: SSH로 포트 포워딩(로컬↔원격)
SOCKS 프록시: 애플리케이션 수준 프록시(브라우저에서 SOCKS 설정)
Shadowsocks / V2Ray 등: 검열 우회용 경량 터널링 프로토콜

4) 터널의 장점

프라이버시 보호: 내부 트래픽(요청 헤더·본문 등)을 중간에서 읽을 수 없음
우회(차단 회피): DPI는 터널 내부의 원목적지를 모름 → 우회 가능
보안: 공용 Wi‑Fi 등에서 트래픽 도청 방지

5) 한계 / 주의점

터널 종단 IP는 노출: 네트워크 장비는 터널 끝점의 IP를 본다 → 그 IP를 차단하면 우회 실패
종단 신뢰 필요: 터널 끝점(예: VPN 서버)은 내부 트래픽을 볼 수 있으므로 신뢰해야 함
지연/성능: 우회 경로 때문에 지연이 늘거나 속도 저하 발생 가능
DNS 처리 필요: DNS가 평문이면 도메인 노출 → DoH/DoT 또는 DNS를 터널로 보내야 완전 은닉

6) 터널 vs 단순 암호화 (헷갈릴 때)

HTTPS(종단 간 암호화): 브라우저↔원서버가 직접 TLS로 암호화된 통신. 이때도 IP/SNI/DNS는 노출될 수 있음.
터널: 브라우저→(암호화)→터널끝점 (그 끝점이 다시 원서버와 통신). 터널은 원서버 IP/DNS/SNI를 클라이언트 네트워크에서 숨기는 데 효과적.

7) 실용 예시 (왜 우리가 중계서버를 종단으로 쓰는지 연결)

차단자가 SNI나 DNS로 특정 사이트를 막는 상황에서, 클라이언트가 원서버에 직접 가지 않고 우회서버를 터널 종단으로 쓰면 클라이언트 네트워크에는 우회서버 IP만 보이고 원서버는 안 보이므로 차단을 우회할 수 있습니다.

터널(우회 서버) 구조에서 핵심은 **“클라이언트 → 터널 끝점(중계 서버) → 원서버”**입니다.

여기서 클라이언트 네트워크/ISP/DPI가 볼 수 있는 건 터널 끝점의 IP뿐이에요.

1️⃣ 터널 끝점 IP 노출 문제

클라이언트가 접속하려는 원서버 IP는 네트워크에 안 보이지만, 터널 끝점 IP는 보임.
DPI나 ISP는 터널 끝점 IP를 차단하면 해당 터널로 가는 트래픽 자체를 막을 수 있음.
따라서 단순히 “터널을 쓰면 무조건 차단 회피 가능”은 아니고, 끝점 IP가 차단되면 접속 불가합니다.

2️⃣ 현실적 우회 서비스의 대응

우회 앱/서비스는 차단자를 피하기 위해 다음과 같은 전략을 씁니다:

전략	설명
대규모 IP 풀	여러 수천~수만 개 IP를 사용해 터널 끝점으로 배치 → 일부 IP 차단되어도 나머지로 연결 가능
IP 회전	일정 시간마다 터널 끝점 IP 변경 → 차단자가 IP를 추적/차단해도 빠르게 회피
CDN 기반 프록시	클라우드 제공업체(예: Cloudflare) IP를 터널 끝점으로 사용 → IP를 막기 어렵게 만듦
혼합 트래픽	정상 트래픽과 우회 트래픽을 섞어 DPI가 식별하기 어렵게 함

3️⃣ 결론

맞아요, 터널 끝점 IP는 노출되고, 차단될 수 있습니다.
따라서 완전 무적의 우회는 불가능하고, **우회 서비스는 ‘끝점 IP를 자주 바꾸거나 대규모 풀로 제공’**하여 차단을 우회합니다.
핵심 포인트: 원서버 IP와 도메인을 숨겨도, 터널 끝점 IP는 항상 네트워크에 보이므로 우회 가능성은 끝점 IP 전략에 달려 있음.

이건 CDN 구조와 인터넷 라우팅 특성을 이해하면 명확해집니다. 🔑

1️⃣ CDN 구조 간단히

CDN(Content Delivery Network)은 전 세계에 분산된 서버 네트워크입니다.

사용자가 example.com에 접속하면, **가장 가까운 CDN 서버(IP)**가 응답합니다.
CDN 서버는 원본 서버(origin server) 대신 콘텐츠를 제공하고, 트래픽을 캐시하거나 프록시 역할을 합니다.
즉, 하나의 도메인에 대해 수많은 IP가 존재하고, 위치마다 IP가 다르게 배정됩니다.

2️⃣ 왜 IP 차단이 어려운가

IP 주소가 많고 분산돼 있음
- 한 CDN 도메인은 수십~수백~수천 개 IP를 가질 수 있습니다.
- DPI/ISP가 모든 IP를 차단하려면 엄청나게 많은 IP를 추적·차단해야 함 → 현실적으로 어렵습니다.
동적/지역별 IP 배정
- 같은 도메인이라도 사용자의 위치나 라우팅 정책에 따라 다른 IP를 할당합니다.
- 즉, IP를 막아도 다른 지역 IP로 자동 연결 → 차단 회피됨.
정상 트래픽과 혼합됨
- CDN IP는 일반 웹사이트 트래픽, 클라우드 서비스 트래픽과 겹치는 경우가 많습니다.
- DPI/ISP가 CDN IP를 무작정 차단하면 정상 서비스도 같이 막혀버려서 부작용이 큼 → 쉽게 차단하기 힘듦.

3️⃣ 그래서 우회 서비스가 CDN을 활용하는 이유

우회 터널을 CDN IP 뒤로 연결하면:
1. DPI는 실제 원서버 IP를 못 보고, 클라이언트가 접속한 IP는 “CDN IP”로 보임.
2. IP 차단을 시도해도 CDN의 분산·다양한 IP 때문에 차단이 어렵거나 부작용 발생.
3. 원서버와 ~ 클라이언트 사이의 트래픽은 CDN에서 처리/암호화 → 차단 회피 가능.

✅ 정리

CDN은 전 세계 수많은 서버와 IP를 가지고 있고, 지역·라우팅별로 IP가 바뀌기 때문에 특정 CDN IP만 차단하는 것은 현실적으로 어렵다.
그래서 HTTPS 우회 서비스나 도메인 프론팅에서는 CDN IP를 터널 끝점으로 활용하면 DPI 차단을 회피하기 쉬워집니다.
단, 완전 무적은 아니고, CDN IP 풀 전체를 차단하면 트래픽이 막힐 수 있음 → 현실적으로 어렵지만 불가능은 아님.

“유니콘 HTTPS 같은 앱은

구현 방식에 따라 ‘HTTPS 프록시’처럼 동작할 수도 있고,

기기 전체 트래픽을 잡아내는 로컬 VPN(또는 그 조합)처럼 동작할 수도 있다” 는 겁니다.

아래에 핵심 차이와 보통 쓰이는 방식, 그리고 특정 연결만 터널링하는지 여부와 그 확인법을 정리할게요.

1) 두 가지 대표적인 방식 (개념)

A. 프록시 기반(HTTP(S) 프록시 / SOCKS)

브라우저나 앱이 프록시 설정을 가지고 있거나, 앱별로 프록시를 지정하면,
해당 애플리케이션의 요청만 프록시 서버(또는 CONNECT 터널) 로 보내집니다.
장점: 설정된 앱/도메인만 선택적으로 우회 가능.
단점: 모든 앱이 프록시를 지원하지는 않음(특히 모바일 앱).

B. 로컬 VPN 기반 (Android의 VpnService 등)

앱이 기기에서 로컬 VPN 엔드포인트를 만들고(루트 필요 없음), 모든(또는 선택한) 트래픽을 그 로컬 인터페이스로 캡처함.
캡처한 트래픽을 내부 규칙에 따라 직접 중계서버로 보내거나(터널링), 아니면 로컬 프록시에서 처리한 뒤 중계로 전달.
장점: 앱별 프록시 설정 불필요 — 모든 앱의 트래픽을 가로챌 수 있음. 또한 도메인/앱 기반으로 선택적(=특정 연결만) 터널링(스플릿 터널) 가능.
단점: 로컬 VPN 권한 필요, 중계서버 신뢰 문제.

2) 유니콘 HTTPS 같은 “HTTPS 우회 앱”은 보통?

많은 모바일 우회 앱들은 로컬 VPN 방식을 사용합니다. 이유: 루트 없이도 모든 앱의 트래픽을 가로챌 수 있고, SNI/DNS 처리를 제어하기 쉬움.
그러나 어떤 앱은 프록시 설정 + 브라우저 확장 형태로 특정 연결(브라우저 트래픽)만 우회시키기도 합니다.
결국 앱마다 다르다 — 구현에 따라 ‘프록시형’일 수도 있고 ‘로컬 VPN형’일 수도 있음.

3) “특정 연결만 터널로 보낸다” — 가능한가?

네, 가능하고 실제로 많이 사용됩니다. 방식 예:

앱 단위: 특정 앱(예: 브라우저) 트래픽만 터널링.
도메인 단위: 특정 도메인/호스트로 가는 요청만 우회.
포트/프로토콜 단위: 예: HTTPS(443)만, 또는 특정 포트 제외 등.
구현은 로컬 VPN에서 룰(화이트/블랙리스트)을 적용하거나, 프록시 설정 + PAC 파일(Proxy Auto-Config)을 사용해 제어합니다.

4) 어떻게 확인할 수 있나? (내 기기에서 직접 검사)

앱 권한 확인
- Android: 앱이 VPN 권한(VpnService)을 요청했는지 확인 → 로컬 VPN 기반일 가능성 높음.
외부에서 보는 IP 확인
- https://whatismyip 등에서 아이피 확인
- 앱을 켰을 때 IP가 바뀌면(우회 서버 IP로) → 트래픽이 외부 서버로 터널되고 있다는 신호.
프록시 설정/PAC 확인
- 브라우저나 시스템 프록시 설정에 프록시 항목이나 PAC 사용 여부 확인.
앱 내부 설정 보기
- “선택적 우회(앱/도메인 선택)” 같은 UI가 있으면 특정 연결만 터널링하는 기능 제공.

5) 장단점(간단)

프록시형(앱/브라우저만): 가볍고 선택적, 설정 필요.
로컬 VPN형(기기 전체): 강력하고 모든 앱에 적용 가능, 그러나 끝점 신뢰 필요(우회 서버가 내 트래픽을 볼 수 있음).

“트래픽(trafﬁc)” = 네트워크를 통해 오가는 데이터의 흐름이라는 개념이에요. 단계별로 정리할게요.

1️⃣ 트래픽이란?

트래픽(Traffic) = 네트워크를 통해 주고받는 모든 데이터 패킷
- 예: 웹사이트 접속 시 주고받는 HTTP 요청/응답, HTTPS 패킷, 이메일, 메시지 등
네트워크 관점에서 보면 **작은 데이터 조각(패킷)**으로 쪼개져서 이동
- 패킷: 출발지 IP, 목적지 IP, 포트 / 헤더, 내용(데이터) 포함

즉, 트래픽 = “클라이언트와 서버가 주고받는 모든 데이터 패킷”입니다.

2️⃣ “우회 서버가 트래픽을 볼 수 있다”의 의미

클라이언트 → 터널 → 우회 서버 → 원서버 구조
- 클라이언트는 터널로 모든 패킷을 보내고, 암호화된 상태로 우회 서버까지 전송
- 우회 서버가 암호화를 풀고(origin 서버로) 요청을 전달함
- 원서버의 응답도 우회 서버가 받아서 다시 클라이언트로 전달
이 과정에서 우회 서버가 볼 수 있는 것
- 암호화되지 않은 경우: HTTP 요청/응답 내용, URL, 쿠키, 헤더 등
- 암호화된 경우: HTTPS라면 내부 내용은 볼 수 없음(암호화 유지), 하지만
  - 어떤 도메인에 접속하는지(SNI/Host)
  - 어떤 IP로 요청을 보내는지
  - 패킷 크기, 요청 횟수, 타이밍 등 메타데이터는 볼 수 있음
쉽게 말하면:

우회 서버는 클라이언트가 “어디로 무엇을 보내고 있는지”를 중계하므로, 네트워크 상에서 실제 요청을 만들어 보내는 역할을 수행하고, 따라서 트래픽의 흐름을 볼 수 있다는 것

3️⃣ 예시

클라이언트가 웹사이트 example.com에 접속한다고 가정:

클라이언트 --암호화 터널--> 우회 서버 --HTTP 요청--> example.com

암호화된 HTTPS: 우회 서버가 암호화 해제 후 example.com으로 요청 → 우회 서버는 URL, 헤더 등 볼 수 있음
평문 HTTP: 클라이언트 → 우회 서버로 가는 패킷 그대로 볼 수 있음

즉, **우회 서버는 클라이언트와 원서버 사이에 있는 ‘중계자’**이므로, 필요하면 트래픽을 읽거나 기록할 수 있습니다.

4️⃣ 결론

트래픽 = 네트워크를 오가는 데이터 흐름, 패킷 단위로 이동
우회 서버가 트래픽을 볼 수 있다 = 중계 서버가 클라이언트가 보내는 요청과 서버 응답을 볼 수 있음, 암호화 여부에 따라 내용 일부 혹은 전체
그래서 우회 서비스 신뢰가 중요: 서버가 로그를 기록하거나 데이터를 수집할 수 있음

우회서버(또는 프록시)가 TLS/HTTPS 연결을 종단(terminate) 하면

그 서버는 암호를 풀고(복호화해서) 요청/응답의 내용(HTTP 헤더·URL·본문·쿠키 등)을 모두 볼 수 있다.

아래에 왜 그런지, 언제 보이는지/안 보이는지, 어떻게 확인하고 방지할 수 있는지 차근차근 정리할게요.

1) TLS(HTTPS)가 어디서 암호화되는지부터 이해해야 한다

TLS는 종단 대 종단(end‑to‑end) 으로 암호화되는 것이 원칙이다.
즉, 원칙적으로는 클라이언트 ↔ 원서버 사이의 내용만 복호화 가능해야 함.
그런데 실제로는 중간에 TLS를 ‘종단(terminate)’하는 장치가 있을 수 있음
- 이 장치가 클라이언트 쪽의 TLS 연결을 받아서(복호화) 내부에서 처리하고, 내부에서 다시 원서버로 새 TLS 연결을 맺는(또는 평문으로 전달하는) 형태.
- 이 경우 클라이언트↔우회서버 구간은 하나의 TLS 세션, 우회서버↔원서버는 또 다른 세션이 된다.
- 결과: 클라이언트→우회서버 구간은 우회서버가 평문을 볼 수 있음.

2) 언제 우회서버가 HTTPS 내용을 볼 수 있나? (두 가지 주요 케이스)

A. 우회서버가 TLS를 종료(terminate) 하는 경우 — 내용을 볼 수 있음

예: 기업용 TLS 검사 프록시, 일부 CDN(Cloudflare 등)이나 재정의된 프록시/캐시, 일부 유료 우회 서비스
동작: 클라이언트는 우회서버와 TLS 연결을 수립 → 우회서버가 복호화 → 우회서버가 원서버로 다시 요청(복호화된 내용을 바탕으로)
발생 이유: 캐싱, 콘텐츠 검사(보안), 필터링, 로깅, 최적화 등을 위해

B. 프록시/터널이 단순히 바이트를 전달(tunnel)만 하는 경우 — 내용을 볼 수 없음(복호화 불가)

예: HTTPS 프록시에서 CONNECT로 단순 터널을 만들거나, VPN이 IP 패킷을 그대로 라우팅/암호화만 하는 경우
동작: 클라이언트는 원서버와 직접 TLS 세션을 설정(우회서버는 암호화된 바이트를 그대로 중계) → 우회서버는 내용(페이로드)을 복호화하지 못함
결과: 우회서버는 목적지 IP/SNI(터널 종단이 아닌 경우) 등 메타데이터는 볼 수 있지만 HTTPS 본문·헤더는 못 봄.

3) 실생활 예시(직관적으로)

회사 네트워크: 회사가 직원 PC에 자체 루트CA를 설치하고 TLS 검사 프록시를 둔다 → 직원이 방문한 HTTPS 사이트의 내용을 회사 장비가 복호화해서 볼 수 있음.
Cloudflare 리버스 프록시: Cloudflare가 고객 도메인의 TLS를 종료하면(=Cloudflare가 클라이언트와 TLS 수립) Cloudflare는 그 구간의 평문을 볼 수 있고, Cloudflare↔origin은 별도 연결임(설정에 따라 암호화 가능).
일반 VPN: 대부분의 VPN은 클라이언트→VPN 간의 터널만 만들고, 원서버와의 TLS는 클라이언트가 직접 수립 → VPN은 HTTPS 내용을 보지 못함(단, VPN 서버가 중간에서 복호화하는 구성일 수도 있음).

4) 어떻게 확인하나? (우회서버가 복호화하는지 판단하는 방법)

브라우저에서 인증서(체인) 확인
- 접속한 사이트의 인증서 발급자를 확인. 회사 내부 CA나 프록시 업체의 CA가 보이면 TLS 중간복호화(MITM) 의심.
인증서 핀닝/경고
- 브라우저가 “인증서 호스트 불일치” 또는 “신뢰할 수 없는 인증서” 경고를 띄우면 뭔가 중간에서 바뀐 것.
외부에서 IP 검사
- 우회 앱을 켰을 때 whatismyip 등의 사이트에서 IP가 우회서버 IP로 바뀌는지 확인(이건 단지 터널 여부 확인).
앱 정책/문서 확인
- 우회 서비스가 “트래픽을 복호화하지 않는다(no‑log, no‑inspect)”고 명시하는지 확인.

5) 보호하려면 어떻게 해야 하나?

완전한 개인정보 보호를 원하면:
1. 신뢰할 수 없는 중간서버(우회 서비스, 공용 프록시)에 트래픽을 맡기지 않는다.
2. **종단 간 암호화(예: TLS를 클라이언트→진짜 원서버까지 유지)**를 보장받는다. (기업의 TLS‑inspection 환경에서는 불가능)
3. 인증서 체인 확인/핀닝을 통해 중간자 공격 가능성 탐지.
4. VPN을 쓸 때는 신뢰할 수 있는 VPN 사업자 선택 — VPN 서버가 트래픽을 볼 수 있는지(로그/복호화 여부) 정책으로 확인.
우회가 목적이라면(차단 우회): 보통은 우회서버의 신뢰 문제를 수용하는 대신 차단 회피가 목적. 이때는 우회서버가 트래픽을 볼 수 있다는 사실을 항상 염두에 둬야 함.

6) 한줄 정리

우회서버가 TLS를 종료(terminate)하면 HTTPS의 모든 내용(헤더·본문·쿠키 등)을 볼 수 있다.
우회서버가 단순 터널만 해주면(바이트 포워딩) 내용은 볼 수 없다.
누가 트래픽을 볼 수 있는지는 어떤 지점에서 TLS가 끝나는가(누가 종단을 맡는가) 에 달려 있다.