/network-protocol-diagnostics

name: network-protocol-diagnostics
description: Diagnose modern network protocol failures with evidence, including HTTP version negotiation, QUIC and UDP reachability, TLS and ALPN, Alt-Svc, browser networking, WebRTC ICE/STUN/TURN, MoQ relay logs, proxies, CDNs, firewalls, NAT, packet captures, qlog, server logs, and stack-specific handoffs.

Network Protocol Diagnostics

Purpose

Use this skill when the main job is finding where a protocol path breaks. The goal is to name the failing hop and gather evidence before changing code, configuration, or infrastructure.

Source Check

Check relevant current sources for the protocol under investigation:

• [RFC 9000: QUIC](https://datatracker.ietf.org/doc/rfc9000/)
• [RFC 9114: HTTP/3](https://datatracker.ietf.org/doc/rfc9114/)
• [W3C WebRTC](https://www.w3.org/TR/webrtc/)
• [RFC 8825: Real-Time Protocols for Browser-Based Applications](https://datatracker.ietf.org/doc/rfc8825/)
• [IETF MoQ working group documents](https://datatracker.ietf.org/wg/moq/documents/)

Then check the actual implementation docs: browser, client library, server framework, CDN, proxy, container platform, TURN service, relay, or hosting provider.

Diagnostic Workflow

1. Preserve the symptom:

• exact user-visible failure, status code, browser console line, log line, timeout, media symptom, negotiated protocol, or degraded fallback
• client, server, region, network, host, container, browser, app version, and timestamp

2. Map the path:

• client runtime
• local network, NAT, corporate firewall, VPN, or mobile network
• DNS, SVCB/HTTPS records, TLS, ALPN, Alt-Svc, proxy, CDN, load balancer, origin, container, and service
• STUN/TURN/SFU/relay path for WebRTC or MoQ

3. Gather the narrowest useful evidence:

• browser network panel, WebRTC internals, or client logs
• server/proxy/CDN logs
• `curl` or protocol client output when it proves negotiated version or failure point
• TLS and ALPN inspection
• UDP reachability checks
• qlog or packet capture when transport behavior is genuinely unclear

4. Classify the failure:

• protocol unsupported
• fallback expected but missing
• DNS or certificate issue
• ALPN or Alt-Svc mismatch
• UDP blocked or NAT traversal failed
• proxy/CDN/load balancer does not pass the protocol
• framework or library lacks support
• app code confused signaling, media, transport, or API semantics

5. Choose the next owner:

• protocol skill for design correction
• stack plugin for code changes
• cloud/deployment plugin for infrastructure
• user/manual validation when the missing evidence requires a real browser, network, device, account, relay, CDN, or media endpoint

Output Shape

Return:

1. `Symptom`: exact failure and affected client/server path. 2. `Path`: client, network, proxy/CDN, origin, relay/TURN/SFU, and service boundaries. 3. `Evidence`: logs, negotiated protocol, TLS/ALPN, Alt-Svc, ICE, qlog, packet capture, or command output. 4. `Likely cause`: specific failing hop and why. 5. `Fix owner`: code, config, dependency, cloud/deployment, protocol design, or manual environment. 6. `Validation`: exact repeat check and fallback check.

Guardrails

• Do not change infrastructure before naming the failing hop when read-only evidence is available.
• Do not claim UDP, TURN, HTTP/3, or WebRTC behavior from local success alone if the bug is on a different network.
• Do not paste secrets, TURN credentials, session tokens, full private URLs, or packet captures containing sensitive payloads into reports.
• Do not reduce protocol failures to vague strings like `network error`; name the protocol, hop, and likely cause.