윈도우 애플리케이션 및 UWP용 HTTP 트래픽 디버깅을 위한 Fiddler: 프록시 설정을 포함한 완벽 가이드

설치 및 초기 설정

Fiddler Classic 설치는 약 2분 정도 소요됩니다. 공식 웹사이트에서 설치 파일을 다운로드하고 telerik.com/fiddler 실행하세요. 설치 후 Fiddler는 자동으로 Windows의 시스템 프록시로 설정되며, 포트 127.0.0.1:8888를 사용합니다.

시작하자마자 세 개의 영역이 있는 기본 창을 보게 됩니다:

• 왼쪽 패널 (세션) - 실시간으로 가로챈 모든 요청 목록
• 오른쪽 상단 패널 - 선택된 요청의 세부 사항(헤더, 본문, 매개변수)
• 오른쪽 하단 패널 - 서버의 응답

가장 먼저 해야 할 일은 필터링을 설정하는 것입니다. 그렇지 않으면 Windows의 모든 시스템 트래픽(업데이트, 텔레메트리, OneDrive 등)이 목록에 포함되어 필요한 요청을 찾기 어려워질 수 있습니다. 오른쪽의 Filters 탭으로 이동하여 Use Filters를 활성화하세요. Show only the following Hosts 필드에 관심 있는 도메인을 입력합니다.

또한 세션 자동 저장을 즉시 설정하는 것을 권장합니다: File → Capture Traffic 및 File → Save → All Sessions. 이렇게 하면 나중에 기록된 트래픽으로 돌아가 오프라인에서 분석할 수 있습니다.

HTTPS 트래픽 가로채기: 인증서 설정

기본적으로 Fiddler는 HTTP 트래픽만 가로챕니다. HTTPS(현재 트래픽의 95% 이상)를 처리하려면 SSL 복호화를 설정해야 합니다. Fiddler는 Man-in-the-Middle처럼 작동하여 자신의 루트 인증서를 생성하고 모든 HTTPS 연결을 서명합니다.

HTTPS 가로채기 단계별 설정:

1. Tools → Options → HTTPS를 엽니다.
2. Capture HTTPS CONNECTs에 체크합니다.
3. Decrypt HTTPS traffic에 체크합니다.
4. 드롭다운 목록에서 ...from all processes를 선택합니다.
5. Actions → Trust Root Certificate 버튼을 클릭합니다.
6. Windows 시스템 저장소에 인증서 설치를 확인합니다.
7. Fiddler를 재시작합니다.

이후 Protocol 열에서 HTTPS를 확인할 수 있으며, 요청 및 응답의 복호화된 내용을 볼 수 있습니다.

일부 애플리케이션은 Certificate Pinning을 사용합니다. 이들은 특정 서버 인증서를 확인하고 Fiddler를 통해 작동하지 않을 것입니다. 이 경우 애플리케이션에서 연결 오류가 발생합니다. 핀닝 우회는 이 기사의 범위를 넘는 별도의 주제입니다.

UWP 애플리케이션의 트래픽을 가로채는 방법

UWP(Universal Windows Platform)는 Microsoft Store의 애플리케이션입니다: 메일, 지도, 영화 및 TV, Spotify, Netflix 등. 이들의 특징은 보안상의 이유로 격리된 컨테이너(App Container)에서 실행되며 시스템 프록시를 사용하지 않습니다. 이 때문에 일반적인 Fiddler 설정으로는 이들의 트래픽을 가로챌 수 없습니다.

이 문제를 해결하기 위해 Fiddler는 특별한 도구인 AppContainer Loopback Exemption Utility를 제공합니다. 이 도구는 UWP 애플리케이션을 예외 목록에 추가하여 Fiddler의 로컬 프록시에 접근할 수 있게 합니다.

방법 1 - Fiddler 인터페이스를 통한 설정:

1. 메뉴에서 WinConfig를 선택합니다(툴바의 버튼 또는 Tools → Win8 Loopback Exemptions).
2. 설치된 모든 UWP 애플리케이션 목록이 열립니다.
3. 필요한 애플리케이션을 찾아 체크박스를 클릭합니다.
4. Save Changes를 클릭합니다.
5. UWP 애플리케이션을 재시작합니다.

방법 2 - 명령줄을 통한 자동화:

CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsMaps_8wekyb3d8bbwe"

Microsoft.WindowsMaps_8wekyb3d8bbwe를 필요한 애플리케이션의 패키지 패밀리 이름으로 교체하세요. PowerShell에서 다음 명령어로 찾을 수 있습니다:

Get-AppxPackage | Select-Object Name, PackageFamilyName | Sort-Object Name

예외를 추가한 후 UWP 애플리케이션은 Fiddler를 통해 트래픽을 전송하기 시작합니다. 세션 목록에서 요청을 확인할 수 있으며, 일반적으로 User-Agent 또는 대상 호스트로 쉽게 식별할 수 있습니다.

필터, 중단점 및 요청 변경

Fiddler의 디버깅을 위한 세 가지 강력한 기능은 세션 필터링, 중단점 및 AutoResponder입니다. 각각을 살펴보겠습니다.

세션 필터링

Filters 탭을 사용하면 필요한 요청만 표시할 수 있습니다. 주요 옵션은 다음과 같습니다:

• Show only the following Hosts - 도메인별 필터(예: api.example.com)
• Show only if URL contains - URL의 일부에 대한 필터
• Show only if response Content-Type - JSON, XML, 이미지 등만 표시
• Hide if URL contains - 노이즈 요청 제외(예: telemetry, analytics)

또한 하단의 QuickExec 입력란을 사용하여 빠른 명령을 실행할 수 있습니다. 예를 들어, select status 404는 모든 404 오류 요청을 강조 표시하고, bold api는 URL에 "api"가 포함된 모든 세션을 굵게 표시합니다.

중단점 (Breakpoints)

중단점은 요청이나 응답이 전송되기 전에 중지하고 내용을 수동으로 변경할 수 있게 해줍니다. 이는 코드 디버거의 중단점과 유사하며, HTTP에 적용됩니다.

• Rules → Automatic Breakpoints → Before Requests - 요청 전 모든 요청을 중지합니다.
• Rules → Automatic Breakpoints → After Responses - 응답 전 모든 응답을 중지합니다.
• 세션에서 오른쪽 클릭 → Breakpoint → Break on Request - 특정 URL에 대한 중단점 설정

요청이 중지되면 모든 헤더, 요청 본문, URL을 변경하고 Run to Completion을 클릭하여 계속 진행할 수 있습니다. 이는 변경된 데이터로 애플리케이션의 동작을 테스트하는 데 특히 유용합니다.

AutoResponder

AutoResponder는 서버 응답을 변경하는 도구입니다. "URL이 패턴과 일치하면 이 파일/응답을 반환"하는 규칙을 설정합니다. 사용 예는 다음과 같습니다:

• 실제 백엔드 없이 API의 스텁으로 애플리케이션 테스트
• 서버 오류 시뮬레이션(500, 503, 타임아웃)
• 리소스 변경 - 서버 대신 로컬 버전의 JS/CSS 로드
• 개발 속도 향상 - 느린 외부 API 요청 캐시

Fiddler를 통한 외부 프록시 연결

Fiddler의 중요한 기능 중 하나는 "프록시를 통한 프록시" 모드(upstream proxy)에서 작동하는 것입니다. Fiddler는 로컬에서 트래픽을 가로채고, 이를 외부 프록시 서버로 전달합니다. 이를 통해 요청을 디버깅하면서 IP 주소나 지리적 위치를 변경할 수 있습니다.

이럴 때 필요합니다:

• 기업 프록시를 통해 애플리케이션의 동작 테스트
• 지리적 콘텐츠 확인 - 다른 국가에서 애플리케이션이 어떻게 작동하는지
• 프록시를 사용하는 애플리케이션 디버깅
• IP 제한이 있는 API 테스트(화이트리스트 기준)

Fiddler Classic에서 upstream proxy 설정:

1. Tools → Options → Gateway를 엽니다.
2. Manual Proxy Configuration를 선택합니다.
3. Proxy 필드에 host:port 형식으로 프록시 주소를 입력합니다.
4. 프록시가 인증을 요구하는 경우 - 로그인과 비밀번호를 입력합니다.
5. OK를 클릭하고 트래픽 캡처를 재시작합니다.

Fiddler는 HTTP, HTTPS 및 SOCKS5 프록시를 upstream으로 지원합니다. SOCKS5의 경우 기록 형식이 약간 다릅니다:

socks=proxy.example.com:1080

애플리케이션의 지리적 행동 테스트에는 주거용 프록시가 적합합니다. 이들은 필요한 국가의 실제 가정 사용자 IP를 사용하여 애플리케이션이 해당 지역의 실제 사용자와 동일한 응답을 받도록 합니다. 이는 API가 지리에 따라 다른 콘텐츠를 반환하는 경우 중요합니다.

디버깅 중 대량의 데이터를 빠르게 다운로드해야 하는 경우 데이터 센터 프록시가 적합합니다. 이들은 안정적인 연결과 최소한의 지연을 제공하여 무거운 API 작업 시 유용합니다.

static function OnBeforeRequest(oSession: Session) {
  if (oSession.HostnameIs("api.us-service.com")) {
    oSession["x-OverrideGateway"] = "us-proxy.example.com:8080";
  }
}

실용적인 시나리오: 파싱, API 테스트, 지오 우회

Fiddler를 사용하여 해결하기 편리한 구체적인 작업을 살펴보겠습니다.

시나리오 1: 모바일 애플리케이션의 API 리버스 엔지니어링

애플리케이션에서 작업을 자동화하고 싶지만 공개 API가 없는 경우, 해결책은 Android 에뮬레이터에서 애플리케이션을 실행하거나 Windows 클라이언트를 통해 Fiddler를 프록시로 설정하고 필요한 작업을 수행할 때 모든 요청을 기록하는 것입니다.

기록이 완료되면 엔드포인트, 요청 형식, 인증 헤더, 토큰 등 전체 그림을 얻을 수 있습니다. 이 데이터를 사용하여 자체 클라이언트를 작성하거나 스크립트를 통해 자동화할 수 있습니다.

시나리오 2: 마켓플레이스 파서 디버깅

Wildberries, Ozon 또는 기타 마켓플레이스를 위한 파서를 개발할 때 요청이 차단되는 이유를 이해하기 어려운 경우가 많습니다. Fiddler를 사용하면 브라우저의 요청(통과되는 요청)과 파서의 요청(차단되는 요청)을 비교하고 헤더, 순서, 쿠키 값 또는 TLS 지문에서 차이를 찾을 수 있습니다.

일반적인 발견: 파서가 헤더를 다른 순서로 전송하거나 Accept-Language가 누락되었거나 User-Agent에 Python 버전이 포함되어 있습니다. 이러한 세부 사항을 파서 코드에서 수정하면 차단 가능성을 줄일 수 있습니다.

시나리오 3: 지리적 콘텐츠 테스트

애플리케이션이 다른 국가의 사용자에게 다른 콘텐츠를 표시하는 경우, 해당 국가의 실제 IP로 테스트해야 합니다. 필요한 지역의 upstream 프록시로 Fiddler를 설정하고 애플리케이션을 실행하면 해당 국가의 사용자가 보는 것과 정확히 동일한 내용을 볼 수 있으며, 모든 요청의 전체 로그도 확인할 수 있습니다.

시나리오 4: 애플리케이션의 백그라운드 활동 모니터링

설치된 프로그램이 어디에 "전화"하는지 알고 싶으신가요? Fiddler를 실행하고 프로그램을 시작한 후 5-10분 기다리세요. 세션 목록에 프로그램이 접근한 모든 호스트가 나타납니다. 이는 타사 소프트웨어의 보안 감사, 텔레메트리 또는 원치 않는 연결 여부를 확인하는 데 유용합니다.

시나리오 5: 재생을 위한 요청 내보내기

Fiddler는 가로챈 요청을 cURL 형식으로 내보낼 수 있으며, 이를 즉시 터미널에서 실행하거나 Postman에 붙여넣을 수 있습니다. 세션에서 오른쪽 클릭 → Copy → cURL Request. 이는 요청을 동료에게 전달하거나 API 문서화에 유용합니다.

Fiddler Classic vs Fiddler Everywhere: 무엇을 선택할까

Telerik는 두 가지 제품 버전을 지원하며, 이들 간의 선택이 항상 명확하지는 않습니다. 주요 차이점을 살펴보겠습니다.

Fiddler Classic을 선택해야 할 때: Windows에서만 작업하고, UWP 애플리케이션과 작업해야 하며, 자동화를 위해 FiddlerScript를 사용하거나, 제한 없이 완전 무료 버전이 필요할 때입니다.

Fiddler Everywhere를 선택해야 할 때: macOS 또는 Linux에서 작업하고, 현대적인 인터페이스가 필요하며, 요청의 공유 컬렉션을 통한 팀워크가 중요하거나 CI/CD 파이프라인과의 통합이 필요할 때입니다.

또한 대안으로는 Charles Proxy(유료, macOS에서 인기가 있음), mitmproxy(무료, 콘솔 기반, 매우 유연함), Wireshark(패킷 수준에서 작동, HTTP가 아님) 등을 언급할 수 있습니다. 각 도구는 강점을 가지고 있지만, 대부분의 Windows 애플리케이션 디버깅 작업에 있어 Fiddler Classic이 최적의 선택으로 남아 있습니다.

일반적인 문제 및 해결 방법

Fiddler를 사용할 때 종종 발생하는 일반적인 문제들이 있습니다. 여기 가장 흔한 문제와 해결 방법을 소개합니다.

문제: Fiddler가 켜져 있을 때 애플리케이션이 작동하지 않음

원인: Certificate Pinning, 애플리케이션에 하드코딩된 프록시, 또는 애플리케이션이 Fiddler 인증서를 신뢰하지 않음. 해결 방법:

• Fiddler 인증서를 Local Machine → Trusted Root 저장소에 설치합니다.
• 애플리케이션이 certificate pinning을 사용하고 있는지 확인합니다.
• SSL 예외에 호스트를 추가합니다: Tools → Options → HTTPS → Skip Decryption for following hosts.

문제: Fiddler를 종료한 후 인터넷이 작동하지 않음

Fiddler가 비정상적으로 종료되면서 시스템 프록시를 해제하지 못했습니다. 해결 방법: Windows 설정 → 네트워크 → 프록시를 열고 수동 프록시를 비활성화합니다. 또는 Fiddler를 다시 실행하고 정상적으로 종료합니다.

문제: CONNECT 터널만 보이고 HTTPS 내용이 보이지 않음

HTTPS 가로채기가 설정되지 않았습니다. 인증서 설정 섹션으로 돌아가 Decrypt HTTPS traffic 체크박스가 활성화되어 있고 인증서가 시스템 저장소에 설치되어 있는지 확인하세요.

문제: UWP 애플리케이션의 트래픽이 Fiddler에 나타나지 않음

해당 애플리케이션에 대한 loopback 예외가 추가되지 않았습니다. WinConfig를 사용하고(위의 UWP 섹션에서 설명됨) 예외를 추가한 후 애플리케이션을 재시작하세요.

문제: Upstream 프록시가 작동하지 않음 (연결 오류)

다음을 확인하세요: 프록시의 주소와 포트가 올바른지, 로그인/비밀번호가 정확한지, 프록시 서버에 접근할 수 있는지(Fiddler 없이 직접 연결해보세요). 또한 프록시가 필요한 프로토콜을 지원하는지 확인하세요. 모든 HTTP 프록시가 HTTPS 터널링을 지원하지는 않습니다.

결론

Fiddler는 HTTP 트래픽을 다루는 모든 이에게 필수적인 도구입니다. 실시간으로 모든 요청을 보고, 이를 실시간으로 변경하며, 다양한 조건에서 애플리케이션의 동작을 테스트하고 브라우저 DevTools로는 수행할 수 없는 작업을 해결할 수 있습니다. 특히 loopback 예외 메커니즘을 통한 UWP 애플리케이션 지원은 대부분의 대안에는 없는 독특한 기회입니다.

애플리케이션의 지리적 행동 테스트나 외부 프록시를 통한 작업 확인을 위해서는 Fiddler에서 upstream 프록시를 설정하세요. 특정 국가에서 올바른 테스트를 위해 실제 IP가 필요하다면 주거용 프록시를 고려하세요. 이들은 최대한 현실적인 지리적 환경을 제공하며, 테스트 중인 서비스의 차단 위험을 최소화합니다.

Fiddler Classic부터 시작하세요. 무료이며, 잘 문서화되어 있고 Windows에서의 디버깅 작업의 90%를 처리합니다. 필요가 커짐에 따라 Fiddler Everywhere로 전환하거나 mitmproxy와 같은 전문 도구로 작업 흐름을 보완할 수 있습니다.