Windows 패킷 캡처 실전 — pktmon, netsh trace, Wireshark 선택

「업무 앱의 서버 통신이 한 달에 몇 번 실패한다. 앱 로그에는 『타임아웃』만 나온다. 그때 서버 측 로그에는 대응하는 오류가 없다. 재현 방법을 모른다」—— 장애 조사 상담에서 이 형태는 끊임없이 나옵니다.

앱 로그에는 앱이 「쓰기로 한」 것만 남습니다. 결과가 타임아웃이었다는 것은 알 수 있지만, 접속 요청(SYN)에 응답이 없었는지, 접속은 됐는데 서버가 침묵했는지, RST로 끊겼는지, 패킷이 목적지까지 도달했는지조차, 로그보다 한 단계 아래 — 실제로 선로를 탄 패킷에만 남아 있습니다. Process Monitor가 파일과 레지스트리 접근을 한 단계 아래에서 보는 수단이라면, 패킷 캡처는 통신을 한 단계 아래에서 보는 수단입니다.

flowchart TB
    accTitle: 앱 로그보다 한 단계 아래의 패킷
    accDescr: 앱 로그에는 앱이 쓰기로 한 것만 남고, SYN에 응답이 없었는지, 접속 후 침묵했는지, RST로 끊겼는지, 패킷이 도착했는지조차 실제로 선로를 탄 패킷에만 남는다
    log["앱 로그"] --> dec["앱이 쓰기로 한 것만 남는다"]
    dec --> to["결과는 한 마디 타임아웃"]
    to -->|한 단계 아래를 본다| pkt["실제로 선로를 탄 패킷"]
    pkt --> q1["SYN에 응답이 없었나?"]
    pkt --> q2["접속 후 침묵했나?"]
    pkt --> q3["RST로 끊겼나?"]
    pkt --> q4["목적지까지 도달했나?"]

그림 1: 로그에는 결과만 남고, 타임아웃의 내역은 한 단계 아래의 패킷에만 있다.

사람들이 막히는 전형적인 지점은 「고객사 서버에 Wireshark를 설치할 수 없다」는 제약입니다. 변경 관리나 보안 정책이 조사용 추가 소프트웨어를 승인하지 않는 현장은 드물지 않습니다. 그러나 Windows에는 이미 패킷 캡처 도구가 두 가지 들어 있습니다. pktmon과 netsh trace입니다. 표준 OS 도구로 캡처하고, 얻은 파일을 자사 PC로 가져와 Wireshark로 읽는다 — 이 분업이면 설치가 금지된 현장에서도 패킷을 볼 수 있습니다.

이 글은 중소기업 IT 담당자와 Windows 앱 개발자를 대상으로, pktmon, netsh trace, Wireshark의 선택 기준과 각각의 실전 절차를 정리합니다. 루프백 트래픽의 함정, 클라이언트와 서버 중 어디에서 캡처할지, TLS가 페이로드를 가리는 상황과의 공존, 캡처와 앱 로그의 대조까지를 2026년 8월 시점의 1차 정보로 다룹니다.

1. 먼저 결론

• 「표준 도구로 캡처하고 Wireshark로 읽는다」가 현장의 기본 분업입니다. 고객사 서버에 소프트웨어를 설치할 수 없어도, pktmon과 netsh trace는 Windows에 들어 있습니다. 캡처한 로그를 pcapng로 변환해 자사 기기의 Wireshark로 분석합니다.¹²
• pktmon은 Windows 10 / Windows Server 2019 이후의 표준 패킷 캡처 도구입니다. 필터 등록, 시작, 중지, 변환의 네 단계로 쓰며, 네트워크 스택의 어느 구성 요소가 패킷을 버렸는지(드롭 이유)를 볼 수 있는 점이 독자적인 강점입니다.³⁴
• netsh trace는 더 오래된 표준 도구이며, ETW 공급자를 「시나리오」로 묶어 켤 수 있습니다. 패킷 외에 Windows 구성 요소 내부 이벤트도 남기고, persistent=yes면 캡처가 재부팅을 넘을 수 있습니다.⁵⁶
• 두 도구 모두 ETL을 쓰며, Wireshark는 그대로 열 수 없습니다. pktmon은 pktmon etl2pcap으로, netsh trace는 Microsoft의 오픈 소스 etl2pcapng로 pcapng로 변환합니다.¹²
• Microsoft 자신도 「먼저 pktmon, 부족하면 netsh trace, 프로토콜 분석은 Wireshark」를 가리킵니다. 이 글의 분업은 그 공식 권고를 따릅니다.⁷
• 기본값으로 pktmon은 각 패킷의 처음 128바이트만 기록합니다. Wireshark에서 페이로드를 읽을 계획이면, 시작할 때 --pkt-size 0(패킷 전체 기록)을 잊지 마십시오.⁸
• localhost로 가는 트래픽은 일반 캡처에 나타나지 않습니다. NIC를 거치지 않기 때문입니다. Wireshark에서는 Npcap의 루프백 어댑터를, 표준 도구에서는 pktmon의 스택 내 캡처를 쓰십시오.⁹
• TLS가 페이로드를 가려도 알 수 있는 것이 많습니다. 접속 수립, TLS 핸드셰이크 성패, RST, 어느 쪽이 침묵했는지는 암호화된 상태에서도 보입니다. SSLKEYLOGFILE을 통한 복호화는 개발 환경 전용 기법입니다.¹⁰
• 캡처에는 통신 그 자체가 들어 있습니다. 자격 증명과 개인정보가 포함될 수 있다고 보고, 필요 최소 캡처와 인도 전 좁히기를 절차에 넣으십시오.

2. 세 가지 캡처 도구와 선택 기준

먼저 세 도구의 역할을 한 표로 정리합니다.

한 문장으로, pktmon과 netsh trace는 「캡처」 도구이고, Wireshark는 「읽기」 도구입니다. Wireshark도 캡처할 수 있지만, 설치할 수 없는 곳에서는 쓸 수 없습니다. 반대로 표준 도구의 ETL을 텍스트로 변환해 읽을 수는 있으나, 표시 필터와 TCP 분석 없이 들여다보는 것은 고역입니다. 「현장에서 표준 도구로 캡처하고, pcapng로 변환해 자사 기기의 Wireshark로 읽는다」가 제약이 있는 현장의 최단 경로입니다.

flowchart TB
    accTitle: 표준 도구로 캡처하고 Wireshark로 읽는다
    accDescr: 현장에서는 pktmon 또는 netsh trace로 ETL을 캡처하고, 각각 변환 도구로 pcapng로 바꾼 뒤 자사 기기의 Wireshark로 분석한다
    pk["pktmon（표준）"] --> etla["ETL 파일"]
    ns["netsh trace（표준）"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["자사 기기 Wireshark로 분석"]

그림 2: 현장에서는 표준 도구로 ETL을 캡처하고, pcapng로 변환해 자사 기기의 Wireshark로 읽는다.

Microsoft의 패킷 손실 조사 가이드도 같은 형태입니다. 먼저 pktmon으로 캡처해 원인을 좁히고, 부족하면 netsh trace start scenario=InternetClient 같은 구성 요소 수준 추적으로 옮기며, 프로토콜 동작은 Wireshark로 분석합니다.⁷

패킷이 실제로 보여주는 것을 읽기 위한 전제로, Ethernet, IP, TCP, 애플리케이션 데이터가 쌓인 계층의 그림도 도움이 됩니다. 계층 해부는 「OSI 참조 모델을 확실하게 이미지화하기」에 있습니다.

3. pktmon 실전 — 필터, 시작, 중지, 변환

pktmon의 기본 흐름은 네 단계입니다. 관리자 권한 터미널에서 실행합니다.

:: 1. 먼저 필터를 등록해 대상을 좁힌다(서버 192.168.10.20의 TCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. 캡처 시작. 패킷 전체를 기록하고 1GB 링 버퍼로 덮어쓴다
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. 사건을 재현한다. 기다리는 동안 counters로 양과 폐기를 확인할 수 있다
pktmon counters --drop-reason

:: 4. 중지한 뒤 Wireshark용 pcapng로 변환
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. 등록한 필터를 정리한다(필터는 명시적으로 지울 때까지 남는다).
::    주의: filter remove는 이름을 지정할 수 없으며 등록된 필터를 「모두」 삭제한다.
::    다른 조사의 필터가 남아 있을 수 있는 환경에서는 먼저 pktmon filter list로 확인한다
pktmon filter remove

flowchart TB
    accTitle: pktmon 기본 절차
    accDescr: 필터로 대상을 좁히고, 캡처를 시작하고, 장애를 재현하고, 중지하고, etl2pcap으로 pcapng로 변환한 뒤 마지막으로 등록한 필터를 제거한다
    fa["1. filter add로 대상을 좁힌다"] --> st["2. start --capture로 캡처 시작"]
    st --> re["3. 장애를 재현한다"]
    re -.-> ct["counters로 양과 드롭을 확인"]
    re --> sp["4. 중지"]
    sp --> cv["etl2pcap으로 pcapng 변환"]
    cv --> rm["5. filter remove로 정리"]

그림 3: pktmon은 필터 등록에서 시작해 캡처, 중지, 변환으로 이어지고, 마지막에 필터를 명시적으로 제거한다.

유념할 점:

• 캡처를 시작하기 전에 필터를 등록하십시오. Microsoft 문서도 전체 트래픽 캡처는 너무 시끄럽기 때문에 시작 전에 필터를 적용할 것을 강하게 권합니다. 필터는 IP 주소, 포트, MAC 주소, 프로토콜, VLAN ID 등을 지정할 수 있고, 최대 32개까지 등록할 수 있습니다. 여러 필터는 OR입니다. 어느 하나에 맞으면 패킷이 기록됩니다.³
• pktmon 필터는 출발지와 목적지를 구분하지 않습니다. -i 192.168.10.20은 「이 주소가 출발지이든 목적지이든」입니다. 방향은 변환 후 Wireshark 표시 필터로 좁히십시오.³
• 기본 패킷 크기는 128바이트입니다. 헤더 분석에는 충분하지만, 애플리케이션 데이터까지 보려면 --pkt-size 0으로 패킷 전체를 기록하십시오.⁸
• 로그 기본은 circular(링 버퍼) 모드이며, 기본 크기는 512MB입니다. --file-size로 상한을 바꿀 수 있고, --log-mode real-time은 화면에 실시간으로 찍으며 로그 파일을 만들지 않습니다. 먼저 실시간 모드로 관심 트래픽이 실제로 보이는지 확인한 뒤 본 캡처를 잡으면, 빈 촬영을 피할 수 있습니다.⁸

flowchart TB
    accTitle: pktmon 필터가 적용되는 방식
    accDescr: 등록한 여러 필터는 OR 일치로 기록하고, 지정 주소는 출발지와 목적지를 구분하지 않으며, 방향은 변환 후 Wireshark 표시 필터로 좁힌다
    f1["필터 1"] --> orc["하나라도 맞으면 기록"]
    f2["필터 2"] --> orc
    f3["필터 3（최대 32）"] --> orc
    orc --> rec["캡처 로그에 기록（OR）"]
    rec -.-> nodir["출발지와 목적지를 구분하지 않음"]
    nodir -.-> ws["변환 후 Wireshark에서 방향을 좁힘"]

그림 4: 여러 필터는 OR로 동작하고, 호스트가 출발지인지 목적지인지는 변환 후 Wireshark에서 좁힌다.

3.1. pktmon만 할 수 있는 일 — 패킷이 버려진 위치를 본다

Wireshark와 대비되는 pktmon의 독자적 가치는 단일 NIC가 아니라 네트워크 스택 안의 여러 지점에서 패킷을 캡처하고, 어디서 왜 버려졌는지(드롭)를 보고할 수 있다는 점입니다. 패킷이 어느 구성 요소까지 도달했고 어디서 사라졌는지를 볼 수 있으므로, 「MTU 불일치」나 「VLAN 필터」 같은 드롭 이유가 전수 조사 없이 원인으로 이어집니다.⁴

flowchart TB
    accTitle: pktmon은 스택 안의 여러 지점에서 캡처한다
    accDescr: pktmon은 단일 NIC가 아니라 네트워크 스택 안의 여러 지점에서 패킷을 캡처하므로, 어느 구성 요소까지 도달했고 어디서 버려졌는지를 이유와 함께 보고할 수 있다
    pin["패킷"] --> p1["지점 1에서 캡처"]
    p1 --> p2["지점 2에서 캡처"]
    p2 --> p3["지점 3에서 폐기"]
    p3 -.-> rz["드롭 위치와 이유를 보고"]
    rz -.-> ex["예: MTU 불일치나 VLAN 필터"]

그림 5: 스택 안의 여러 지점에서 캡처하면 패킷이 어디까지 갔고 어디서 드롭됐는지를 이유와 함께 알 수 있다.

• pktmon list는 감시할 수 있는 네트워크 구성 요소(NIC, 프로토콜 스택, 필터 드라이버 등)와 그 ID를 보여 줍니다.
• pktmon counters --drop-reason은 구성 요소별 통과/드롭 카운터와 가장 최근 드롭 이유를 나열합니다. 로그를 분석하기 전의 1차 컷으로 편리합니다.¹¹
• pktmon etl2txt로 텍스트 변환하면 버려진 패킷이 drop과 dropReason과 함께 출력됩니다.³

「OS 안의 무언가가 앱에 도달하기 전에 이것을 버리고 있다」는 의심은 Wireshark만 들여다봐서는 결론이 나지 않습니다. 이 능력은 예를 들어 인바운드 규칙이 없어 방화벽이 버리고 있는 경우를 분리할 때 도움이 됩니다(「Windows 방화벽과 업무 앱」).

한 가지 주의. pktmon은 같은 패킷을 스택의 여러 지점에서 기록하므로, 그대로 pcapng로 변환하면 같은 패킷이 두 번 이상 나타날 수 있습니다. pcapng는 「어느 구성 요소가 캡처했는지」를 싣지 않으므로, Wireshark에서 읽을 때는 --component-id로 한 지점을 고르거나 --drop-only로 드롭만 별도 파일에 넣는 것이 정석입니다.¹

flowchart TB
    accTitle: pcapng 변환 후 같은 패킷이 두 번 나타나는 이유
    accDescr: pktmon은 같은 패킷을 스택의 여러 지점에서 기록하고, pcapng는 어느 구성 요소가 캡처했는지를 유지하지 않아 중복이 나타날 수 있으므로, component-id로 지점을 좁히거나 drop-only 파일로 드롭만 분리한 뒤 변환하는 것이 정석이다
    same["같은 패킷을 여러 지점에서 기록"] --> conv["그대로 pcapng로 변환"]
    conv --> lost["캡처 지점 정보가 넘어가지 않음"]
    lost --> dup["같은 패킷이 두 번 이상 나타남"]
    dup --> c1["--component-id로 지점을 좁힘"]
    dup --> c2["--drop-only로 별도 파일"]

그림 6: 캡처 지점 정보는 pcapng로 넘어가지 않으므로, 변환 전에 지점을 좁히는 것이 정석이다.

4. netsh trace 실전 — 시나리오, ETL, 재부팅을 넘는 캡처

netsh trace는 pktmon보다 오래 Windows에 있는 추적 메커니즘입니다. 특징은 「시나리오」로서 그 문제에 관련된 ETW 공급자 집합 전체를 한 번에 켤 수 있다는 점입니다.⁶

:: List available scenarios and inspect the providers in a scenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Start the capture. Packet capture included, 1GB circular buffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduce the incident, then stop (the merge takes a little time)
netsh trace stop

• capture=yes를 더하면 패킷 캡처가 켜지고, ipv4.address=192.168.10.20 같은 캡처 필터로 대상을 좁힙니다. 필터 목록은 netsh trace show capturefilterHelp에 있습니다.⁶
• 중지하면 ETL 외에 .cab 파일도 나옵니다. .cab에는 어댑터 구성과 OS 빌드 같은 시스템 정보가 들어 있어, 환경 수집을 겸합니다.⁶
• 추적 세션은 한 번에 하나만 실행할 수 있습니다. 다른 캡처를 시작하기 전에 netsh trace show status로 남은 세션이 없는지 확인하십시오.⁶
• persistent=yes를 더하면 세션이 재부팅을 넘습니다. 「재부팅 직후 잠깐 통신이 실패한다」나 「시작 시 서비스 접속이 실패한다」처럼 손으로 제때 시작할 수 없는 장애를 잡는 것은 netsh trace만의 영역입니다.⁵

flowchart TB
    accTitle: netsh trace 시나리오 캡처
    accDescr: 시나리오로 시작하면 ETW 공급자 묶음이 켜지고, capture=yes면 패킷도 캡처되며, 중지하면 ETL 파일과 .cab 파일이 나온다
    sc["시나리오로 시작"] --> pv["공급자 집합을 켠다"]
    sc -->|capture=yes| pc["패킷도 캡처된다"]
    pv --> re["장애를 재현한다"]
    pc --> re
    re --> sp["중지"]
    sp --> etl["ETL 파일"]
    sp --> cab[".cab（시스템 정보）"]

그림 7: 시나리오로 시작하면 공급자 묶음이 켜지고, 중지하면 ETL과 .cab이 나온다.

4.1. ETL을 Wireshark에서 읽게 만들기 — etl2pcapng

netsh trace의 ETL은 Wireshark에서 그대로 열 수 없습니다. Microsoft가 GitHub에 공개한 오픈 소스 도구 etl2pcapng가 netsh trace start capture=yes로 캡처한 ETL 안의 패킷을 pcapng로 변환합니다.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

변환 시 etl2pcapng는 각 패킷과 관련된 프로세스 ID를 패킷 주석으로 씁니다. Wireshark에서 「어느 프로세스의 트래픽인지」를 볼 수 있으면, 같은 서버에서 여러 앱이 통신할 때 도움이 됩니다.²

ETW 이벤트 쪽(시나리오 공급자가 기록한 Windows 내부 이벤트)은 pcapng로 변환되지 않습니다. 이벤트도 보고 싶으면 netsh trace convert input=C:\temp\nettrace.etl로 텍스트 등으로 변환하거나, Windows Performance Analyzer에서 ETL을 여십시오.⁵⁷

flowchart TB
    accTitle: netsh trace ETL을 읽는 길은 둘로 갈린다
    accDescr: ETL 안의 패킷은 etl2pcapng로 pcapng로 변환해 Wireshark에서 읽고, ETW 이벤트는 pcapng로 변환되지 않으므로 netsh trace convert 또는 Windows Performance Analyzer로 읽는다
    etl["netsh trace ETL"] --> pk["패킷"]
    etl --> ev["ETW 이벤트"]
    pk -->|etl2pcapng| pc["pcapng로 변환"]
    pc --> ws["Wireshark에서 읽기"]
    pc -.-> pid["프로세스 ID가 주석으로 남음"]
    ev -.-> no["pcapng로 변환되지 않음"]
    no --> alt["convert 또는 WPA로 읽기"]

그림 8: ETL 중 패킷은 pcapng로 변환해 읽고, ETW 이벤트는 다른 수단으로 읽는다.

5. Wireshark에서 읽기의 첫걸음 — 표시 필터와 TCP 분석

pcapng를 열면 먼저 표시 필터로 잡음을 자릅니다. 자주 쓰는 것은 표에 있습니다.¹²¹³

tcp.analysis.*는 Wireshark가 TCP 시퀀스 번호를 추적해 붙이는 분석 플래그입니다. 재전송, 중복 ACK, 순서 뒤바뀜, ZeroWindow 등을 기계적으로 집어내므로, 읽기의 정석은 먼저 tcp.analysis.flags를 입력해 「문제처럼 보이는」 지점을 나열하는 것입니다.¹³

타임아웃 조사에서는 다음 형태를 순서대로 찾습니다.

1. 3방향 핸드셰이크가 완료됐는가? SYN → SYN/ACK → ACK의 세 패킷이 모두 있는가? SYN이 응답 없이 반복되면 상대에 도달하지 못했거나, 중간에서 조용히 버려진 것입니다(전형적인 방화벽 패턴).
2. 어느 쪽이 RST를 보냈는가? SYN에 즉시 RST가 오면 목적지 포트에 아무도 듣고 있지 않은 것이고, 접속 성립 후의 RST는 한쪽이 접속을 강제로 끊은 것입니다. RST의 출발지 IP가 「누가 끊었는지」의 직접 증거입니다.
3. 재전송이 계속되고 있는가? 같은 세그먼트의 반복 재전송은 확인 응답(ACK)이 송신측에 돌아오지 않는다는 신호입니다. 나간 데이터가 사라졌는지 돌아오는 ACK가 사라졌는지는 한쪽 캡처만으로는 결론이 나지 않습니다(그래서 다음 장의 「양쪽에서 캡처」가 중요합니다). 재전송과 타임아웃은 「TCP 재전송으로 산업용 카메라 통신이 수 초 멈출 때」에서 더 깊게 다룹니다.
4. ZeroWindow가 있는가? 수신 앱이 소켓에서 읽지 않아 수신 버퍼가 가득 찬 신호입니다. 네트워크가 아니라 수신 앱의 설계를 의심할 근거입니다(「TCP에서 Send한 단위대로 Receive할 수 있다는 오해」).

flowchart TB
    accTitle: 타임아웃 조사에서 찾을 형태의 순서
    accDescr: 3방향 핸드셰이크 완료, RST의 유무와 출발지, 계속되는 재전송, 이어서 ZeroWindow를 확인해 원인을 1차로 표시한다
    hs{"SYN에 응답이 왔나?"} -->|아니오| ng["도달하지 않음（전형적인 방화벽）"]
    hs -->|예| rs{"RST가 있나?"}
    rs -->|예| who["RST 출발지가 끊음"]
    rs -->|아니오| rt{"재전송이 계속되나?"}
    rt -->|예| ack["ACK가 돌아오지 않음"]
    rt -->|아니오| zw{"ZeroWindow가 있나?"}
    zw -->|예| app["수신측이 읽지 않음"]

그림 9: 핸드셰이크, RST, 재전송, ZeroWindow 순으로 찾으면 다음에 볼 곳이 좁혀진다.

패킷을 하나씩 읽기 전에, 통계 기능으로 전체 그림을 잡는 것도 도움이 됩니다. [Statistics] → [Conversations]는 「어느 IP 쌍 / 포트 쌍이, 언제부터 언제까지, 얼마나」의 목록이므로, 관심 통신을 특정한 뒤 그 통신만 필터할 수 있습니다. [Statistics] → [I/O Graph]는 시간에 따른 양 그래프이며, 「이 시각부터 한쪽이 침묵했다」 같은 형태가 바로 보입니다. 관심 TCP 통신을 오른쪽 클릭하고 [Follow] → [TCP Stream]을 고르면 그 접속의 교환을 평문으로 통독할 수 있습니다.

flowchart TB
    accTitle: 통계로 그림을 잡고 통신으로 좁힌다
    accDescr: Conversations에서 어느 통신이 언제 얼마나 오갔는지 나열하고, I/O Graph에서 침묵 구간을 잡고, 관심 통신으로 필터한 뒤 TCP 스트림으로 통독한다
    ov["통계로 전체 그림을 잡는다"] --> cv["Conversations의 통신 목록"]
    ov --> io["I/O Graph에서 양을 본다"]
    cv --> flt["관심 통신으로 필터"]
    io -.-> mute["침묵 구간이 보인다"]
    flt --> fs["TCP 스트림으로 통독"]

그림 10: 패킷을 하나씩 읽기 전에 통계로 그림을 잡고, 관심 통신으로 좁힌 뒤 통독한다.

6. 루프백의 함정 — localhost로 가는 트래픽은 NIC를 거치지 않는다

같은 PC의 앱 간 통신 — 예를 들어 업무 앱이 localhost:8080의 중간 서비스에 접속하는 경우 — 을 조사하려다 「Wireshark에 아무것도 안 나온다」에서 막히는 것은 고전적인 함정입니다.

원인은 분명합니다. localhost(127.0.0.1)로 가는 트래픽은 물리 NIC를 거치지 않고 OS 내부 루프백 경로에서 되돌아갑니다. 물리 어댑터를 대상으로 하는 일반 캡처에는 처음부터 보이지 않습니다.⁹

flowchart TB
    accTitle: localhost 트래픽이 캡처에 나타나지 않는 이유
    accDescr: localhost로 가는 트래픽은 물리 NIC를 거치지 않고 OS 내부 루프백 경로에서 되돌아가므로, 물리 어댑터를 대상으로 하는 일반 캡처에는 나타나지 않는다
    app["앱"] --> stack["네트워크 스택"]
    stack -->|외부| nic["물리 NIC"]
    nic --> seen["일반 캡처에 보임"]
    stack -->|localhost| lo["OS 안에서 되돌아감"]
    lo -.-> miss["일반 캡처에 없음"]
    lo -.-> alt["Npcap 루프백 또는 pktmon"]

그림 11: localhost 트래픽은 NIC 앞에서 되돌아가므로, 물리 어댑터 캡처에는 보이지 않는다.

대처는 두 가지입니다.

• Wireshark로 캡처할 때: 캡처 대상으로 Npcap의 「Adapter for loopback traffic capture」를 선택합니다. Windows용 Wireshark 설치 프로그램(3.0 이후)은 Npcap을 포함하므로, Wireshark가 이미 설치되어 있으면 추가 작업 없이 쓸 수 있습니다.⁹
• 표준 도구로 캡처할 때: pktmon은 NIC 바깥이 아니라 네트워크 스택 안의 여러 지점에서 캡처하므로⁴ 루프백 트래픽도 관찰할 수 있습니다. 확실히 하려면, 본 대기 캡처를 잡기 전에 그 기기에서 pktmon start -c -m real-time 실시간 표시로 관심 루프백 트래픽이 실제로 보이는지 확인하십시오.

혼동도 두 가지 조심하십시오.

• 「localhost」는 IPv6 ::1로 해석될 수 있습니다. 앱은 IPv6 ::1에 접속하는데, 조사자는 127.0.0.1(IPv4)만 보고 「트래픽이 없다」고 잘못 결론 냅니다. ip.addr == 127.0.0.1 || ipv6.addr == ::1처럼 표시 필터를 양쪽 주소로 늘리거나, 앱의 목적지 설정을 명시 주소로 하십시오.⁹
• 자기 자신의 실제 IP로 가는 트래픽도 선로에 나가지 않습니다. 같은 PC가 192.168.10.5에서 192.168.10.5로 접속하면, 목적지는 실제 IP이지만 OS는 여전히 내부에서 되돌립니다. 「실제 IP를 지정했으니 NIC를 지난다」는 보장이 아닙니다.

flowchart TB
    accTitle: localhost가 IPv6로 해석될 때의 혼동
    accDescr: 앱의 localhost는 IPv6 ::1로 해석될 수 있고, 조사자가 127.0.0.1만 보면 트래픽이 없다고 잘못 결론 내므로, 표시 필터를 양쪽 주소로 늘리거나 목적지를 명시 주소로 확인한다
    app["앱이 localhost에 접속"] --> v6["실제로는 ::1（IPv6）로 해석"]
    look["조사자는 127.0.0.1만 본다"] --> none["화면에 아무것도 없음"]
    v6 --> none
    none --> fix1["필터를 양쪽 주소로 늘린다"]
    none --> fix2["목적지를 명시 주소로 한다"]

그림 12: localhost가 ::1로 해석되어 127.0.0.1만 보면 「트래픽이 없다」가 되는 혼동을 조심한다.

7. 어디에서 캡처할지 — 한쪽, 양쪽, 시각 동기

캡처의 가치는 「어디에서 잡았는지」로 결정됩니다. 경험 규칙은 다음과 같습니다.

한쪽 캡처는 「내 위치에서 본 사실」만 알려 줍니다. 클라이언트의 계속되는 재전송은, 보낸 패킷이 경로에서 사라졌는지, 서버에 도착하고 응답이 사라졌는지를 구분하지 못합니다. 양쪽에서 캡처해 나란히 놓으면 「클라이언트가 보냈다 / 서버는 받지 못했다」 — 어느 쪽이 침묵했는지 — 를 확정할 수 있습니다. 책임 경계(앱, OS, 네트워크 장치, 상대)를 확정해야 할 때는, 처음부터 양쪽 캡처를 준비할 가치가 있습니다.

flowchart TB
    accTitle: 한쪽 캡처와 양쪽 캡처가 알려 주는 것
    accDescr: 한쪽 캡처는 나간 패킷이 사라졌는지 돌아오는 응답이 사라졌는지를 구분하지 못하고, 양쪽에서 캡처해 나란히 놓으면 어느 쪽이 침묵했는지를 확정한다
    one["한쪽에서 캡처"] --> fact["자기 쪽의 사실"]
    fact --> und["나간 쪽인가 돌아오는 쪽인가?"]
    both["양쪽에서 캡처"] --> mt["나란히 놓는다"]
    mt --> fix["어느 쪽이 침묵했는지"]
    mt -.-> pre["시각 동기가 필요"]

그림 13: 한쪽은 내가 본 사실만 보여 주고, 양쪽을 나란히 놓아야 책임 경계가 처음 확정된다.

7.1. 대조의 전제는 시각 동기

양쪽 캡처를 나란히 놓으려면 두 기기의 시계가 맞아야 합니다. 캡처를 시작하기 전에 시각 차이를 확인하고 기록하십시오.

:: Check time-sync status (sync source, last sync time)
w32tm /query /status

:: Measure the offset against the peer server (5 samples)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart는 자신과 상대 컴퓨터의 시각 차이를 보여 주는 명령이며, 캡처를 나란히 놓을 때 「서버 시계가 +0.8초였다」 같은 보정의 근거가 됩니다.¹⁴ 차이가 큰 환경에서는 시각 동기를 먼저 고친 뒤 캡처하는 편이 결국 더 짧습니다.

flowchart TB
    accTitle: 대조 전에 시각 차이를 확인하는 절차
    accDescr: w32tm으로 자신의 시각 동기 상태를 확인하고, stripchart로 상대 서버와의 차이를 측정해 기록하며, 그 차이를 캡처를 나란히 놓을 때 보정 근거로 쓰고, 차이가 크면 먼저 동기를 고친 뒤 캡처한다
    st["query로 동기 상태를 확인"] --> mc["stripchart로 차이를 측정"]
    mc --> rc["차이를 기록"]
    rc --> use["대조 시 보정의 근거"]
    mc -.-> big["차이가 크면 먼저 동기를 고친다"]

그림 14: 캡처 전에 시각 차이를 측정해 기록하고, 나란히 놓을 때 보정의 근거로 쓴다.

7.2. 「언제 일어날지 모른다」일 때 — 링 버퍼

재현 조건을 모르는 장애에서는, 링 버퍼를 돌려 두고 장애가 나면 멈추는 것이 기본입니다.

• pktmon: 기본이 circular 모드입니다. --file-size로 상한(MB)을 정하면 오래된 패킷이 덮어쓰입니다.⁸
• netsh trace: maxSize=1024 filemode=circular로 지정합니다.⁵
• Wireshark: [Capture] → [Options] → [Output]에서 「여러 파일 + 링 버퍼」를 설정할 수 있습니다. 파일 크기나 시간으로 순환하며 최신 N개만 남기므로, 디스크 사용 상한을 두고 오래 돌릴 수 있습니다.¹⁵

어떤 경우든, 현장 담당자와 장애가 나면 「먼저 시각을 적고, 그다음」 캡처를 멈춘다는 규칙을 공유하십시오. 링 버퍼는 기다릴수록 과거를 지우므로, 발생에서 중지까지의 경로가 길면 관심 구간이 덮어쓰입니다.

flowchart TB
    accTitle: 링 버퍼 캡처로 기다리기
    accDescr: 재현 조건을 모르는 장애에서는 링 버퍼를 돌려 두고, 장애가 나면 시각을 적어 즉시 멈춘다. 늦게 멈추면 오래된 패킷이 덮어쓰여 관심 구간이 사라진다
    st["링 버퍼 캡처를 시작"] --> wt["돌려 두고 기다린다"]
    wt --> ev["장애가 발생한다"]
    ev --> memo["시각을 적는다"]
    memo --> sp["즉시 중지"]
    wt -.-> ow["오래된 패킷이 덮어쓰인다"]
    ow -.-> late["늦은 중지는 관심 구간을 지운다"]

그림 15: 링 버퍼는 기다릴수록 과거를 지우므로, 시각을 적었으면 즉시 멈춘다.

8. TLS가 페이로드를 가리는 문제 — 그래도 보이는 것

오늘날 대부분의 업무 트래픽은 TLS(HTTPS)입니다. 「암호화되어 있으면 캡처는 소용없다」고 생각하기 쉽지만, 타임아웃 조사에서 알고 싶은 대부분은 암호화를 그대로 두고도 보입니다.

• TCP 접속이 수립됐는지(3방향 핸드셰이크)
• TLS 핸드셰이크가 어디까지 갔는지 — ClientHello에 ServerHello가 돌아왔는지, 핸드셰이크 중에 RST나 alert로 끊겼는지
• ClientHello의 목적지 호스트 이름(SNI), 협상된 TLS 버전
• 접속이 올라간 뒤 어느 쪽이 보내기를 멈췄는지. 침묵의 위치, 재전송, RST, 또는 정상 종료(FIN)

즉 「접속할 수 없다」, 「중간에 끊긴다」, 「응답이 안 온다」의 분리는 페이로드 복호화가 거의 필요 없습니다. 암호화가 잃는 것은 「무엇을 말했는지」이고, 「누가, 언제 침묵했는지」는 남습니다.

flowchart TB
    accTitle: TLS 캡처에서 보이는 것과 보이지 않는 것
    accDescr: 암호화는 애플리케이션 데이터 페이로드만 가리고, TCP 접속 수립, TLS 핸드셰이크 성패, SNI와 TLS 버전, RST, 어느 쪽이 침묵했는지는 암호화를 그대로 두고도 보인다
    tls["TLS 트래픽 캡처"] --> vis["보임"]
    tls --> hid["보이지 않음"]
    vis --> v1["TCP 접속 수립"]
    vis --> v2["TLS 결과와 SNI"]
    vis --> v3["RST / 누가 침묵했는지"]
    hid --> h1["앱 데이터 페이로드"]

그림 16: 암호화가 잃는 것은 페이로드뿐이고, 통신의 뼈대는 TLS를 그대로 두고도 읽을 수 있다.

그래도 페이로드가 필요하면, Wireshark는 SSLKEYLOGFILE 환경 변수로 내보낸 세션 키로 TLS를 복호화할 수 있습니다. 지원은 Firefox, Chrome, Chromium 기반 Edge, OpenSSL 계열 라이브러리 등 일부 구현에 한정되며, Windows 표준 SChannel(WinHTTP나 WinINET을 쓰는 앱)은 이 메커니즘을 지원하지 않습니다.¹⁰ 「세션 키가 파일에 쓰인다」는 것은 그 파일을 가진 사람이 통신 전체를 복호화할 수 있다는 뜻이므로, 운영 기법이 아니라 개발 환경에서의 재현과 디버깅으로 다루십시오.

flowchart TB
    accTitle: SSLKEYLOGFILE 복호화의 동작과 한계
    accDescr: SSLKEYLOGFILE로 쓴 세션 키로 Wireshark가 TLS를 복호화할 수 있지만, Firefox와 Chrome 계열 등 일부 구현만 지원하고 SChannel은 지원하지 않으며, 키 파일을 가진 사람은 통신을 복호화할 수 있어 개발 환경 전용 기법으로 다룬다
    env["SSLKEYLOGFILE을 설정"] --> key["세션 키를 쓴다"]
    key --> ws["Wireshark에서 읽기"]
    key -.-> risk["키를 가진 사람이 복호화 가능"]
    risk -.-> dev["개발 전용"]
    env -.-> sup["일부 TLS 스택만"]
    sup -.-> sch["SChannel: 지원 없음"]

그림 17: 세션 키를 쓰면 복호화할 수 있지만, 지원 구현이 한정되고, 키의 성격상 개발 환경 전용 기법이다.

트래픽이 내부 프록시를 거치면, 캡처에 나타나는 목적지는 프록시 서버이고, TLS는 CONNECT 터널 안에서 흐릅니다. 앱이 어느 프록시로 향하는가라는 선행 질문은 같은 날의 동반 글 「사내 프록시와 Windows 앱 — WinINET, WinHTTP, .NET의 프록시 해석 정리」에 정리되어 있습니다.

9. 앱 로그와의 대조 — 시각을 같은 축에 놓기

캡처만으로는 결론이 잘 나오지 않습니다. 실전에서 결정적인 수는 앱 로그의 한 줄과 패킷의 한 왕복을 같은 시간축에 놓는 것입니다.

절차는 다음과 같습니다.

1. 앱 로그에서 장애 시각을 특정합니다(예: 10:23:41의 타임아웃 예외). 타임아웃 값이 30초이면 시작은 10:23:11 근처여야 합니다.
2. Wireshark의 시각 표시를 [View] → [Time Display Format] → [Date and Time of Day]로 바꾸고, 표시 필터로 구간을 좁힙니다(frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00"처럼 시각으로도 필터할 수 있습니다).
3. 그 구간에서 5장의 순서(핸드셰이크 → RST → 재전송 → ZeroWindow)를 확인합니다. 「로그의 타임아웃 시각 30초 전에 SYN이 나갔고, 그 뒤는 SYN 재전송뿐」까지 맞출 수 있으면, 로그의 「타임아웃」은 「이 캡처 지점에서는 응답이 전혀 돌아오지 않았다」는 관찰로 바뀝니다(SYN이 상대에 도달하지 않았는지, 돌아오는 SYN/ACK가 귀로에서 사라졌는지는 이 캡처 지점만으로는 확정할 수 없습니다. 확정하려면 서버에서 캡처해 나란히 놓으십시오).
4. 캡처 시각과 로그 시각의 차이(7.1절에서 측정한 시각 차이, 로그의 시간대 표기)를 반드시 보정하십시오. 몇 초의 대조 오차가 엉뚱한 통신을 범인으로 찍습니다.

flowchart TB
    accTitle: 앱 로그와 패킷을 나란히 놓는 절차
    accDescr: 앱 로그에서 장애 시각을 특정하고, 타임아웃 값에서 시작 시각을 역산하며, Wireshark에서 표시 필터로 구간을 좁히고, 순서대로 형태를 확인한 뒤, 시각 차이를 보정하고 같은 시간축에 놓는다
    lg["1. 로그에서 장애 시각을 특정"] --> rev["타임아웃 값에서 시작을 역산"]
    rev --> flt["2. 표시 필터로 구간을 좁힘"]
    flt --> chk["3. 5장 순서로 형태를 확인"]
    chk --> adj["4. 시각 차이를 보정"]
    adj --> done["로그의 한 마디가 관찰이 된다"]

그림 18: 로그 시각에서 구간을 좁히고, 형태를 확인하고, 시각 차이를 보정한 뒤 같은 축에 놓는다.

조사 결과를 제3자(벤더, 통신사, 고객사 네트워크 담당)에게 넘길 때는, 넘기기 전에 필터로 잡음을 자르는 것이 예의이자 안전 조치입니다. Wireshark에서 표시 필터로 관심 통신을 좁히고 [File] → [Export Specified Packets]로 「표시된 패킷만」 저장하면, 필요한 범위만의 작은 pcapng가 됩니다.

마지막으로 취급 주의. 캡처 파일에는 통신 그 자체가 들어 있습니다. 평문 프로토콜의 자격 증명, HTTP 쿠키와 API 키, 메일이나 보고서의 내용, 개인정보가 포함될 수 있습니다. 다음 세 가지를 캡처 절차와 한 세트로 결정하십시오.

• 필요 최소 캡처: 캡처 전 필터(3장과 4장)로 대상을 좁히고, 시간창을 가능한 한 짧게 유지합니다. 고객사 환경에서 「일단 전부 캡처」는 하지 마십시오
• 넘기기 전에 좁히기: 관심 통신만 내보내고, 무관한 제3자 트래픽을 넣지 마십시오. 민감 부분이 남으면 수신측과 마스킹이나 다른 수단을 합의하십시오
• 보관과 삭제: 캡처 파일을 어디에, 얼마나 두고, 언제 삭제할지 정하고, 조사가 끝나면 삭제하십시오

flowchart TB
    accTitle: 캡처 파일을 넘기기 전에 결정할 세 가지
    accDescr: 캡처에는 통신 그 자체가 들어 있으므로, 캡처 전 필터와 시간창으로 최소로 좁히고, 인도 전에 관심 통신만 추출해 무관한 트래픽을 넣지 않으며, 보관 장소와 기간을 정해 조사 후 삭제하는 것을 캡처 절차와 한 세트로 결정한다
    cap["캡처 = 트래픽"] --> p1["최소로 캡처"]
    cap --> p2["먼저 대상을 추출"]
    cap --> p3["보관 기간을 정하고 삭제"]
    p2 -.-> exp["필터하고 내보내기"]

그림 19: 최소 캡처, 인도 전 좁히기, 보관과 삭제를 캡처 절차와 한 세트로 결정한다.

10. 정리

• 앱 로그의 「타임아웃」보다 한 단계 아래에는, 실제로 선로를 탄 패킷의 사실이 있습니다. SYN에 응답이 없었는지, RST로 끊겼는지, 재전송이 계속됐는지, ZeroWindow가 나타났는지에 따라 다음에 볼 곳이 바뀝니다.
• Wireshark를 설치할 수 없는 현장에서도 Windows 표준 pktmon과 netsh trace로 캡처할 수 있습니다. 표준 도구로 캡처하고, 자사 기기의 Wireshark로 읽는다 — 그 분업이 기본형입니다.
• pktmon은 네 단계입니다. 필터 등록 → pktmon start --capture → pktmon stop → pktmon etl2pcap. 기본은 128바이트로 잘리므로, 페이로드가 필요하면 --pkt-size 0을 잊지 마십시오. 드롭 위치와 이유를 보는 것은 pktmon만의 강점입니다.
• netsh trace는 ETW 공급자를 시나리오로 묶어 캡처하고, persistent=yes면 재부팅을 넘을 수 있습니다. ETL은 etl2pcapng로 pcapng로 변환해 읽습니다.
• Wireshark에서는 tcp.analysis.flags에서 시작해 핸드셰이크, RST, 재전송, ZeroWindow를 그 순서로 찾으십시오. Conversations와 I/O Graph로 먼저 그림을 잡은 뒤 좁히면 더 빠릅니다.
• localhost로 가는 트래픽은 NIC를 거치지 않으므로 평범한 방법으로는 캡처할 수 없습니다. Npcap의 루프백 어댑터 또는 pktmon의 스택 내 캡처를 쓰십시오.
• 양쪽에서 캡처해 나란히 놓으면 「어느 쪽이 침묵했는지」가 확정됩니다. 전제는 시각 동기(w32tm)입니다. 재현 조건을 모르는 장애는 링 버퍼로 기다리십시오.
• TLS 아래에서도 통신의 뼈대는 보입니다. 복호화(SSLKEYLOGFILE)는 개발 환경 전용 기법으로 다루고, 캡처 파일 자체는 기밀로 다루며, 최소 캡처, 좁히기, 삭제를 운영에 넣으십시오.

패킷 캡처는 「네트워크 전문가의 도구」로 생각되기 쉽지만, 실전에서는 앱 로그와 나란히 놓을 때 비로소 의미가 생기는 앱 측 조사 도구입니다. 다음번에 조사가 「타임아웃」 한 마디에서 멈추면, 한 단계 아래를 보러 가십시오.

관련 기사

• TCP 재전송으로 산업용 카메라 통신이 수 초 멈출 때 - RFC1323 타임스탬프와 재전송 대기의 구분
• TCP에서 Send한 단위대로 Receive할 수 있다는 오해 ── 바이트 스트림으로 다루기 위한 수신 설계
• OSI 참조 모델을 확실하게 이미지화하기 ── HTTP 요청 1개를 7계층으로 해부한다
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기
• Windows 방화벽과 업무 앱 ── 인바운드 규칙은 인스톨러에서 등록한다
• 사내 프록시와 Windows 앱 — WinINET, WinHTTP, .NET의 프록시 해석 정리

관련 상담 영역

합동회사 코무라소프트는 「업무 앱의 통신이 가끔 실패하는데 원인을 모르겠다」, 「고객사 환경에서만 나는 접속 오류를 분리하고 싶다」와 같은 통신 기인 장애 조사를 다룹니다. 캡처 설계(어디서, 무엇을, 얼마나 잡을지), Wireshark 분석, 앱 로그와의 대조, 앱 측 수정을 하나의 연속 작업으로 맡습니다.

• Windows 앱 개발
• 불량 조사·원인 분석
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Wireshark를 설치할 수 없는 고객사 서버에서 패킷을 어떻게 캡처하나요?

Windows 표준 도구인 pktmon 또는 netsh trace를 쓰면 추가 소프트웨어를 설치하지 않고 캡처할 수 있습니다. pktmon은 관리자 권한 터미널에서 필터를 등록하고, pktmon start --capture로 캡처를 시작한 뒤 pktmon stop으로 멈춥니다. 얻은 ETL 파일은 pktmon etl2pcap으로 pcapng로 변환할 수 있어, 분석은 자사 PC의 Wireshark로 가져가 하면 됩니다. 「표준 도구로 캡처하고 Wireshark로 읽는다」가 설치 제한이 있는 현장의 기본 분업입니다.

pktmon과 netsh trace 중 어느 쪽을 써야 하나요?

OS에 pktmon이 있으면(Windows 10 / Windows Server 2019 이후) 먼저 pktmon부터 쓰십시오. 명령이 단순하고, 네트워크 스택의 어느 구성 요소가 패킷을 버렸는지(드롭 이유)를 볼 수 있으며, pcapng 변환도 자체로 끝납니다. netsh trace가 유리한 것은 pktmon이 없는 구형 OS에서 캡처할 때, Windows 구성 요소의 ETW 이벤트를 시나리오로 모을 때, persistent=yes로 재부팅을 넘는 캡처가 필요할 때입니다. Microsoft의 장애 조사 자료도 이 순서, 즉 먼저 pktmon, 부족하면 netsh trace를 가리킵니다.

localhost(127.0.0.1)로 가는 트래픽이 Wireshark에 나타나지 않는 이유는 무엇인가요?

localhost로 가는 트래픽은 물리 NIC를 거치지 않고 OS 내부 루프백 경로에서 되돌아갑니다. 물리 어댑터를 대상으로 하는 일반 캡처에는 처음부터 보이지 않습니다. Wireshark에서는 Npcap의 「Adapter for loopback traffic capture」를 선택하면 루프백 트래픽을 캡처할 수 있습니다. pktmon은 네트워크 스택 안에서 캡처하므로 루프백 트래픽도 관찰할 수 있습니다. 또 「localhost」가 IPv6의 ::1로 해석되어 127.0.0.1만 보고 있으면 화면에 아무것도 안 나오는 혼동도 흔하니, 주소를 명시해 확인하십시오.

패킷 캡처에서 HTTPS(TLS) 통신의 내용을 볼 수 있나요?

애플리케이션 데이터의 페이로드는 암호화되어 있어 보이지 않습니다. 다만 TCP 접속·절단, TLS 핸드셰이크 성패, RST로 끊김, 어느 쪽이 응답을 멈췄는지라는 「통신의 뼈대」는 암호화된 상태에서도 알 수 있으므로, 대부분의 타임아웃 조사는 TLS를 그대로 두고 진행할 수 있습니다. 페이로드가 필요하면 SSLKEYLOGFILE을 통한 복호화가 있지만, Firefox나 Chrome 계열 등 일부 TLS 구현만 지원하며 Windows 표준 SChannel은 지원하지 않습니다. 비밀 키 정보를 파일로 쓰는 메커니즘이므로 개발 환경 전용으로 다루십시오.

캡처 파일을 외부 지원 창구에 보내도 안전한가요?

그대로 보내는 것은 위험합니다. 캡처에는 통신 그 자체가 들어 있어, 평문 프로토콜의 자격 증명, 쿠키, API 키, 개인정보가 포함될 수 있습니다. 먼저 캡처 시점에 필터와 시간대를 필요한 최소로 좁히고, 넘기기 전에 Wireshark 표시 필터로 대상 통신만 추출해 내보내십시오. 그래도 남는 민감 부분은 수신측과 처리 방법(마스킹, 다른 수단으로 전달)을 합의한 뒤에 보내십시오. 캡처 파일의 보관 기간과 삭제 시점도 미리 정해 두십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.