1. URL은 어디서 동작하나 & 필터는 어디에 두나 (오늘: 1편 전체 제공)
2. 한국의 정부·통신사 차단 방식 요약(HTTP, SNI, 법·정책 맥락)
3. SNI는 왜 복호화 없이 보이나? TLS 1.3/ECH까지 한 번에 정리
4. macOS에서 Wireshark로 SNI 확인하는 법(QUIC 포함)
5. Wireshark가 SNI를 파싱하는 소스 코드 포인트
6. GoodbyeDPI의 원리: ‘변조’가 아니라 ‘가시성 교란·미끼 패킷’
7. Windows 네트워크 스택: GoodbyeDPI(WinDivert/WFP) vs Wireshark(Npcap/NDIS)
8. FastAPI에서 401 vs 403: 인증/인가 설계와 표준 헤더 실무

---

1편. URL은 어디서 동작하고, 필터는 어디에 두어야 할까?

title: "URL은 어디서 동작하고, 필터는 어디에 두어야 할까?"
slug: url-layer-and-filter-points
series: "URL·TLS·SNI·필터링·DPI 실전 가이드"
author: EX Corp. Tech Team
summary: "URL은 L7 개념이다. HTTPS 시대엔 중간에서 ‘도메인’ 정도만 보인다. 목적별로 DNS/SNI/프록시/WAF/엔드포인트 중 어디에 필터를 둘지 결정하는 실전 가이드."
tags: [URL, TLS, SNI, HTTPS, 필터링, WAF, 프록시, DNS, QUIC]
reading_time: "10분"
cover_image_suggestion: "L3~L7을 층층이 표현하고 필터 배치 지점을 핀으로 표시한 다이어그램"

한눈에 핵심

• URL은 L7(애플리케이션) 개념이고, 네트워크에 “그 자체로” 흘러다니지 않는다.
• HTTPS에서는 중간에서 볼 수 있는 게 IP/포트/트래픽 메타데이터 + SNI(도메인) 정도다. 경로·쿼리는 암호화.
• 외부 웹까지 경로/쿼리 기반으로 통제하려면 TLS 가시화 가능한 포워드 프록시나 엔드포인트 에이전트가 사실상 필요.
• 내 서비스 보호는 리버스 프록시/API 게이트웨이+WAF가 정석.

---

1) URL, 어디에서 ‘동작’하나?

URL(scheme://host:port/path?query#fragment)은 앱이 파싱하고 HTTP(S) 요청의 라인/헤더로 전달되는 L7 데이터다.
즉, 브라우저·SDK·서버/프록시가 URL을 해석·정규화하고, 네트워크 레이어는 이를 세션 페이로드로 운반할 뿐.

TLS가 끼면 무슨 일이?

1. DNS로 IP 확인
2. TCP(또는 QUIC/UDP) 연결
3. TLS 핸드셰이크(여기서 SNI=호스트명이 평문으로 포함, ECH 예외)
4. 이후부터 HTTP 내용(경로/쿼리/헤더/본문)은 암호화

---

2) 누가 뭘 볼 수 있나(요약 표)

위치	평문 HTTP	HTTPS(TLS 1.2/1.3, H2/H3)
L3/L4 장비	IP/포트/도메인/경로/본문 전부 보일 수 있음	IP/포트 + 트래픽 특성만. 보통 **SNI(호스트)**는 보임, 경로/쿼리/본문은 암호화
DNS 필터	도메인 기준 통제	동일 (단, DoH/DoT면 중간자에선 조회 자체가 안 보임)
포워드 프록시(복호화 無)	전체 URL·본문 가시	도메인 정도(CONNECT 터널)
포워드 프록시(복호화 有)	전체 가시	전체 가시(L7 정책 가능)
리버스 프록시/WAF	전체 가시	종단 복호화로 전체 가시

포인트: HTTPS는 도메인 외에는 중간에서 안 보인다. 경로/쿼리를 기준으로 외부 웹을 막으려면 가시화가 필요.

---

3) 필터를 둘 수 있는 7곳과 장단점

A. DNS 레이어

• 도메인 단위 차단/허용, 카테고리/평판 연동 용이
• 빠르고 쉬움. 단, 경로/쿼리 불가, DoH/DoT 우회 고려

B. L3/L4 방화벽

• IP·포트 기반. 고성능
• CDN 공유 IP로 인한 오탐 리스크, 도메인/경로 인지 불가

C. SNI 필터링

• 도메인 단위 통제 가능(HTTPS에서도)
• ECH 보급 시 가시성 약화, 서브도메인 세분화 한계

D. 포워드 프록시(SWG/SASE 포함)

• 복호화 有면 경로·쿼리·헤더·본문까지 정밀 정책 가능, DLP/악성파일 검사 연계
• 단, 프라이버시·법규·성능·예외리스트 운영 이슈

E. 리버스 프록시/API 게이트웨이 + WAF (인바운드)

• 내 서비스 앞단: 정규화→화이트리스트 라우팅, OWASP 룰, 레이트리밋/봇 차단, 스키마 검증
• 외부 사이트 필터링 용도는 아님

F. 애플리케이션 레벨

• 권한/파라미터/입력 검증 등 가장 정교
• 코드 릴리스 필요, 앞단 방어 없으면 부담↑

G. 엔드포인트(브라우저 확장/에이전트)

• 실제 전체 URL 가시
• 배포/관리 필요, 우회 가능성

---

4) 목적별 추천 배치

• 외부 웹을 경로/쿼리까지 세밀 통제
  → 포워드 프록시(+TLS 가시화) 또는 엔드포인트 에이전트
• 도메인 수준만으로 충분
  → DNS 필터 + (보조) SNI/L4
• 내 웹/API 보호
  → 리버스 프록시/API 게이트웨이 + WAF에서 정규화·화이트리스트 1차, 앱 레벨 2차
• 모바일/전용앱 (핀닝 등)
  → 프록시 가시화 우회 가능. 게이트웨이/앱 내부 정책 중심 설계

---

5) 실무 팁: URL 정규화 & 우회 패턴 차단

• 정규화: 스킴/호스트 소문자화, 기본 포트 제거, ./.. 세그먼트 제거, 퍼센트 인코딩 단 한 번만 해석
• 이중 인코딩/우회 패턴(%2e%2e/, 혼합 인코딩) 탐지 시 차단
• 화이트리스트 우선: 허용 경로·메서드·파라미터 명시(정규식 앵커 사용, 과도 백트래킹 방지)
• 헤더 위변조 방지: Host/:authority 일치, X-Forwarded-* 신뢰 경계
• 로그 표준화: 정규화된 URL 저장, 민감 파라미터 마스킹
• HTTP/3 고려: UDP 443 차단/형상으로 서비스 영향 주의
• 암호화 추세: ECH 보급 시 SNI 필터 효과↓ → 도메인 통제는 DNS로, 세밀 통제는 종단/프록시로

---

6) NGINX 예시(리버스 프록시·API 앞단)

server {
  listen 443 ssl http2;
  server_name api.example.com;

  # (TLS 설정 생략)

  # 우회 패턴 차단
  if ($request_uri ~* "%25|%2e%2e|/\.\./") { return 400; }

  # 허용 메서드만
  if ($request_method !~ ^(GET|POST|PUT|DELETE)$) { return 405; }

  # 화이트리스트 라우팅
  location = /api/v1/health { proxy_pass http://app; }
  location ~ ^/api/v1/(users|orders)(/|$) { proxy_pass http://app; }

  # 그 외 일괄 거부
  location / { return 404; }
}

---

7) 체크리스트 (도입 전 질문지)

• 우리가 통제하려는 대상은 외부 웹 전반인가, 자체 서비스 인바운드인가?
• 도메인 수준으로足한가, 경로/쿼리까지 필요한가?
• TLS 가시화의 법적·내부정책·성능 이슈는? 예외 리스트 어떻게 운영?
• HTTP/3/QUIC 트래픽 비율은? 방화벽·프록시가 제대로 처리할 수 있나?
• 로깅 시 개인정보/토큰은 어떻게 마스킹·보관할 것인가?

---

8) TL;DR

• URL은 L7, 중간장비는 HTTPS에서 도메인(SNI)까지만 본다(ECH 예외).
• 외부 사이트를 정밀 통제하려면 프록시 가시화나 엔드포인트가 필요.
• 내 서비스 보호는 리버스 프록시+WAF로 정규화→화이트리스트가 정석.

---