Inspecting Claude Code’s Network Traffic with Linux Namespaces and MITM Proxying (Part 1) – blog

Skip to content

This is an analysis of how Claude Code initiates web scraping requests. You might be surprised to find that claude code could scrape from an API endpoint, or from the host that’s running claude code. In this series, you will learn how to use network namespaces, tcpdump and MITMproxy to isolate a client’s network traffic and experimentally discover whether claude code is scraping content from an api endpoint or from the host that’s running claude code. Code for this project is available at my github.

You installed Claude Code. It ships with built-in network tools (WebFetch & WebSearch) that can reach out to the internet on your behalf. Each use requires your explicit approval (unless you’ve configured auto-approve policies). But here’s the question nobody answers in the documentation:

What exactly does it send and where is it sending requests from?

Inspecting Claude Code’s Network Traffic with Linux Namespaces and MITM Proxying

In the proxied fetch model, the request would route through Anthropic’s servers. The target system sees Anthropic’s IP, and Anthropic’s infrastructure handles the fetched content:

These two models have very different privacy and security implications. Which one does Claude Code actually use? This guide answers that question empirically.

When claude code “searches the web,” whose IP address does the search engine see- yours or Anthropic’s? What telemetry does it send home?

These aren’t hypothetical concerns. If you’re running an AI agent that has built-in network tools on a machine that can reach internal services, you need to know its traffic pattern. This guide shows you how you can discover this behavior directly and what I found during my analysis.

What you’ll learn

By the end of this guide, you’ll be able to:

Isolate a single process’s network traffic on Linux using network namespaces: this technique ensures you won’t have other process’s packets in the capture

Extract destination hostnames from encrypted TLS traffic using SNI and DNS metadata

Decrypt HTTPS traffic for a specific process using MITM proxying with mitmproxy, scoped so only that one process is affected

Classify all traffic the Claude CLI generates: API calls, web fetches, web searches, telemetry, and MCP connections

Understand the security implications of a local-fetch model: What it means for your LAN and internal services

Prerequisites

You should be comfortable with:

Linux terminal and shell scripting

Basic networking concepts (IP addresses, ports, TCP, DNS)

What tcpdump does (even if you don’t use it daily)

What TLS/HTTPS provides (encrypted transport)

You’ll need installed:

Linux with kernel namespace support (any modern distro)

tcpdump, iproute2 (ip command), iptables

Python 3 (for the analysis scripts)

mitmproxy (pipx install mitmproxy or pip install mitmproxy) for the decryption sections

The claude CLI on your PATH

slirp4netns for the rootless approach to collecting packets (available in most distro repos)

git clone git@github.com:CaptainMcCrank/claude-netns.git<br>cd claude-netns<br>chmod +x claude-sandbox.sh claude-mitm.sh rootless-capture.sh mitm-capture.sh

Key Concepts Before We Start

This guide relies on Linux networking and TLS concepts that may be unfamiliar or counterintuitive.

There is no per-process packet capture on Linux. Linux’s packet capture mechanism (AF_PACKET) attaches to interfaces, not processes. There is no tcpdump --pid. If you capture on an interface shared by every process on the box, you get everything mixed together. The first half of this guide builds a workaround for this using network namespaces.

HTTPS does not hide all metadata. TLS encrypts the payload. The payload includes the URL path, headers, and body. But the destination hostname leaks in plaintext via the TLS SNI extension in every ClientHello, and DNS queries leak it again via standard unencrypted lookups. You can’t read the content, but you can see where traffic goes. That partial visibility turns out to be enough to answer the most important question (where does WebFetch connect?) without any decryption at all.

MITM proxying is a standard debugging technique. The same TLS interception mechanism used by attackers on hostile networks is used every day by Burp Suite, Charles Proxy, Fiddler, mitmproxy, and corporate TLS inspection appliances. Despite the fact that these tools have legitimate applications, many corporate security tools treat them as hacking tools. Only perform MITM Proxying on networks and clients you’re authorized to inspect. Do not proceed if you have any doubts about your authorization for such techniques. While this is all legitimate debugging and auditing, there’s no way for a 3rd party to independently distinguish if this work is an attack or authorized. Many corporate security teams configure monitoring tools to alarm when they see tools such as MITM proxy...