How I Used a Coding Agent to Diagnose a Disney+ Network Problem

Disney+ was unusable from my home network. It buffered or dropped to poor quality on every device, every time. Netflix and a speed test to Vienna both worked, and Disney+ worked over 4G. The failure was tied to Disney+ traffic on my home network.

A 31.9-second packet capture eventually showed Disney’s video traffic crawling along a lossy Akamai route while another CDN transfer on the same client and connection ran hundreds of times faster. Reaching that diagnosis took eleven rejected hypotheses. Claude Code handled much of the testing; I kept checking its conclusions against playback.

I was using Claude Code, running Opus 5, through T3 Chat, a graphical interface for directing coding agents. Given a goal, the agent can inspect files, execute commands, interpret results, choose the next experiment, and continue without waiting for instructions at every step.

I gave the agent read access to my infrastructure repository, live router configuration, and captured network traffic. It gathered evidence and pursued the investigation within those boundaries. I kept network changes under manual control.

The initial observations already constrained the investigation. Every device on the home network failed, making a client-specific problem unlikely. The same Disney+ account worked over 4G, pointing away from the service itself. Netflix and the speed test showed that the connection was not generally broken. Any explanation had to account for a problem shared by Disney+ traffic leaving the home network.

Using Claude Code for infrastructure troubleshooting

I started the Claude Code session with an infrastructure problem. My home-infrastructure repository documented the intended topology, services, DNS configuration, and router. The agent read the repository, inspected the live router over SSH, and turned the symptom into testable hypotheses. It used the familiar coding-agent loop of inspecting an environment, acting through tools, reading the results, and revising the plan against a running network.

The first pass established a healthy local baseline. The agent checked the EdgeRouter rather than inferring its state from the repository. The commands and outputs below are abridged for readability.

ssh router 'top -bn1 | head -12'

%Cpu(s): 0.4 us, 0.3 sy, 99.0 id, 0.0 wa

ssh router \
  'cat /proc/sys/net/netfilter/nf_conntrack_count;
   cat /proc/sys/net/netfilter/nf_conntrack_max'

1016
262144

CPU capacity and connection tracking were not under pressure. The WAN interfaces also reported no errors. The agent then tested the PPPoE path MTU directly:

for size in 1400 1440 1464 1472; do
  ping -D -s "$size" -c 2 18.172.242.35
done

1464-byte payload: succeeds
1472-byte payload: fails
effective path MTU: 1492

That was the expected result for PPPoE and ruled out an MTU black hole. General throughput was healthy too:

curl -o /dev/null -s \
  -w 'speed=%{speed_download} B/s\n' \
  'https://speed.cloudflare.com/__down?bytes=50000000'

speed=58679867 B/s

Roughly 470 Mbps of general download capacity made router overload, exhausted connection tracking, a broad throughput problem, and path MTU increasingly poor explanations. The lack of QoS remained a potential weakness, but it did not fit a constant failure isolated to Disney+.

Testing the wrong CDN

Early CDN measurements made CloudFront look dramatically slower than Cloudflare, and the agent briefly suspected ISP rate limiting. Small transfers had exaggerated DNS, connection, TLS, and slow-start costs. When the agent tried a larger byte-range download, it initially received no data at all:

curl -o /dev/null -s -r 0-20000000 \
  -w 'speed=%{speed_download} size=%{size_download} code=%{http_code}\n' \
  'https://corretto.aws/downloads/latest/amazon-corretto-21-x64-linux-jdk.tar.gz'

speed=0 size=0 code=302

curl -L -o /dev/null -s -r 0-40000000 \
  -w 'speed=%{speed_download}\n' \
  'https://corretto.aws/downloads/latest/amazon-corretto-21-x64-linux-jdk.tar.gz'

run 1: 67.9 MB/s
run 2: 67.0 MB/s
run 3: 68.5 MB/s
CloudFront POP: BUD50-P1

The corrected result caused the agent to retract the rate-limiting theory. Disney’s video stream later proved to use Akamai, so this CloudFront test still could not say whether the video path was healthy.

The blocked telemetry domains

The next resolver comparison showed that NextDNS was sinkholing several Disney-related analytics and telemetry domains:

dig +short cws.conviva.com @192.168.0.1
dig +short cws.conviva.com @8.8.8.8

# router / NextDNS
0.0.0.0

# public resolver
199.127.194.128

Similar blocking affected Adobe and Nielsen telemetry domains. I allowlisted them in NextDNS, and the agent verified that the change was live:

cws.conviva.com              199.127.194.128
disneyplus.hb.omtrdc.net      63.140.62.120
disney.demdex.net             52.50.131.252
secure-dcr.imrworldwide.com   46.137.123.222

Allowlisting the domains corrected their DNS answers, but Disney+ still buffered. I reported what I could see: “I have fixed these, but the video still seem to be loading slow.”

Because playback still failed, the agent resumed the investigation.

The agent then tested several more explanations:

Hypothesis	Why it looked plausible	What broke it
Slow DNS without router caching	Cold Disney lookups took 37–59 ms through the router.	Repeated lookups fell to roughly 10–11 ms; that could not explain sustained buffering.
Slow Akamai authentication or TLS	The first request took about 0.53 seconds.	Warm requests completed in about 0.04 seconds. It was a cold-start effect.
Incorrect geolocation	A Disney CDN name resolved to a Santiago endpoint roughly 280 ms away.	The application never contacted that hostname. It was irrelevant to playback.
Incorrect EDNS Client Subnet	NextDNS advertised a different Hungarian client subnet from the home’s public address.	Controlled ECS queries for the real media hostname still selected healthy local addresses. The mismatch did not reproduce the bad route.
The local *.home.lan DNS wildcard	It was conspicuous in the supplied infrastructure configuration.	No evidence connected a private home namespace to Disney+ traffic.

The *.home.lan detour came from a DNS-related setting in the repository, despite there being no evidence that the private namespace affected Disney+. Broad access sped up useful checks, but it also made irrelevant configuration easy to turn into a hypothesis. Keeping the commands and results visible made those hypotheses easy to reject.

Capturing the Disney+ stream

None of the DNS, CDN, or router tests used traffic from a Disney+ playback attempt. I started a stream and recorded a packet capture lasting 31.9 seconds.

capinfos disney_stream.pcapng

Number of packets: 7298
Capture duration:  31.865100 seconds
Capture size:      6.5 MB
Data bit rate:     1637 kbps

The entire capture averaged about 1.6 Mbps. The agent then extracted the TLS Server Name Indication to identify the video server used by the application:

tshark -r disney_stream.pcapng \
  -Y 'tls.handshake.extensions_server_name' \
  -T fields \
  -e ip.dst \
  -e tls.handshake.extensions_server_name

2.17.147.58  vod-akc-eu-west-2.media.dssott.com

vod-akc-eu-west-2.media.dssott.com was the hostname used by the video flow. The earlier CloudFront measurements had not tested it. The agent analyzed this connection and compared it with other traffic captured at the same time.

The video flow was losing packets

The TCP conversation statistics showed two large downloads from the same client:

tshark -r disney_stream.pcapng -q -z conv,tcp

Akamai video     3,017 kB in 19.93 s   ~1.2 Mbps
CloudFront image 2,509 kB in 0.058 s   ~347 Mbps

The CloudFront transfer moved almost as much data in 58 milliseconds as the Akamai video flow moved in 20 seconds. Both occurred on the same client and home connection during the same capture.

The agent counted TCP problems on the video flow:

for flag in \
  tcp.analysis.retransmission \
  tcp.analysis.fast_retransmission \
  tcp.analysis.lost_segment \
  tcp.analysis.duplicate_ack \
  tcp.analysis.spurious_retransmission \
  tcp.analysis.zero_window \
  tcp.analysis.window_full
do
  printf '%-38s ' "$flag"
  tshark -r disney_stream.pcapng \
    -Y "ip.addr==2.17.147.58 && $flag" |
    wc -l
done

tcp.analysis.retransmission              716
tcp.analysis.fast_retransmission         553
tcp.analysis.lost_segment                283
tcp.analysis.duplicate_ack               926
tcp.analysis.spurious_retransmission       0
tcp.analysis.zero_window                   0
tcp.analysis.window_full                   0

The video connection contained 3,453 packets, of which 716 were marked as retransmissions. The absence of zero-window and window-full events gave no sign that the client was failing to consume data. No retransmissions were marked as spurious. The next test was therefore aimed at the exact Akamai address, not another substitute CDN.

NextDNS selected a lossy Akamai cluster

A live test reproduced the loss against the video server identified in the capture:

for ip in 2.17.147.58 18.239.255.27 1.1.1.1 192.168.0.1; do
  ping -c 60 -i 0.2 -q "$ip"
done

2.17.147.58      35.0% loss   14.7 ms average RTT
18.239.255.27     0.0% loss    4.4 ms average RTT
1.1.1.1           0.0% loss    9.1 ms average RTT
192.168.0.1        0.0% loss    2.3 ms average RTT

ICMP loss can be caused by rate limiting, but the packet capture had already shown TCP retransmissions on the same address. The healthy controls also ran from the same client and connection.

The agent then compared DNS answers for the video hostname:

dig +short vod-akc-eu-west-2.media.dssott.com @192.168.0.1
dig +short vod-akc-eu-west-2.media.dssott.com @8.8.8.8

# router / NextDNS
2.17.147.x

# Google DNS
31.46.5.x

Repeated lookups returned the same split. Tests against several addresses in each cluster produced different results:

NextDNS-selected 2.17.147.x   40–47% loss   ~15 ms RTT
Google-selected  31.46.5.x     0% loss       ~4 ms RTT

The DNS split accounted for the initial observations. Every device on the LAN used the router’s NextDNS path. Disney+ over 4G used different DNS and network routing. Netflix, speed tests, Disney’s API calls, and its CloudFront-hosted images used other delivery paths.

Applying and verifying the fix

The agent proposed forwarding the affected Disney and Akamai domains to Google DNS while leaving NextDNS in place for everything else. I applied the override on the EdgeRouter:

configure
set service dns forwarding options server=/dssott.com/8.8.8.8
set service dns forwarding options server=/akamaized.net/8.8.8.8
set service dns forwarding options server=/akamai.net/8.8.8.8
commit
save
exit

The router then returned addresses from the healthy cluster:

dig +short vod-akc-eu-west-2.media.dssott.com @192.168.0.1

31.46.5.x

After flushing the DNS caches on the router and MacBook, I opened Disney+ in a browser. The stream played normally. I then tested the television app, and it worked there too.

The original Claude Code transcript ended after the diagnosis and proposed override. I ran the playback tests afterward. The router returned the intended CDN route, the MacBook streamed successfully, and the television confirmed that the original symptom was gone.

The engineer still owns the investigation

Claude Code issued 51 shell commands over roughly 42 minutes. It inspected the repository and router, built test loops, compared resolvers and CDN endpoints, corrected malformed measurements, and parsed a 7,298-packet capture. Given the goal and access to the environment, it chose many of those actions without waiting for me to specify each command.

Running those commands autonomously increased the number of hypotheses I could test and reduced the time spent following each one. Comparing DNS-selected CDN clusters is not an exotic technique, but I would not have reached for it this early when the visible symptom was only “Disney+ buffers.”

I remained responsible for the investigation. I decided what access the agent received, supplied observations it could not collect, reviewed its conclusions, applied the network changes, and verified the result on the MacBook and television. When it generalized from the wrong CDN or promoted blocked telemetry domains to a likely root cause, I had to catch the mismatch.

Even with the wrong turns, the agent covered far more ground in 42 minutes than I would have managed manually. Because the commands and measurements remained visible, I could trace each conclusion and intervene when it outran the evidence. I used the extra capacity, but I still had to sign off on the diagnosis and the change.

Production controls

My home network was a non-production environment. Giving the agent broad read access to its configuration and packet data was an acceptable tradeoff, and I applied the proposed change myself. I would use narrower interfaces for production troubleshooting:

• The agent would query network devices through a controlled service instead of receiving general SSH access.
• Read-only diagnostics and configuration changes would use separate permission boundaries.
• Every command, result, and proposed change would be recorded.
• Changes would require explicit approval through a second channel.
• Each change would include a rollback procedure and a test of the original user-visible symptom.
• Credentials, packet data, and permitted targets would be limited to the current incident.

The agent could still inspect live state and run most of the investigation autonomously. The engineer would retain control over what it could access and when a proposed fix could modify production.

Coding agents as engineering tools

Claude Code handled this infrastructure session with the same loop it uses in a repository: accept a goal, inspect the environment, operate tools, read the results, and choose the next action. T3 Chat made the loop easier to direct, while Claude Code handled much of the execution.

In a web-based chat, I would have copied commands into a terminal, returned the outputs, explained changes in state, and asked for the next test. Here, the agent performed much of that loop itself. I could spend more time checking whether its conclusions matched the system I was observing.

For the next incident, I would provide representative evidence earlier. The packet capture identified the real playback hostname and exposed the healthy and failing flows in the same 31.9-second window. That would have prevented several tests against endpoints that Disney+ was not using.