Gocipher captures TLS secrets by hooking the TLS library of the application: OpenSSL, Go's crypto/tls, and now the JDK's JSSE. Some runtimes give it nothing to hook. Envoy, and so every Istio sidecar, ships its own BoringSSL inside a static binary. A Rust service using rustls has no libssl at all. For these, Spider showed a TCP session whose content could not be read.

Those runtimes can still be asked to write their TLS key log, the same NSS format that SSLKEYLOGFILE produces for Wireshark. The key log fallback reads that log, without any file.

HTTP/3 moves HTTP off TCP and onto QUIC, over UDP. For anyone observing traffic from the network, that is a step backwards. Everything after the first few packets is encrypted, the packet numbers included. Streams, retransmissions and ordering all live inside that encryption. Headers are compressed against a table that is built on separate streams. Most network tools stop at "UDP 443, some bytes".

Spider now decodes HTTP/3 into the same HTTP communications as HTTP/1.x and HTTP/2: method, URI, status, headers, bodies, gRPC calls and SSE events. There is no proxy, no sidecar, and no change to the client or the server.

QUIC encrypts nearly everything, the handshake included. A passive sniffer sees UDP datagrams full of random-looking bytes and a few connection IDs. Spider now reads DNS over QUIC (DoQ, RFC 9250) from that traffic: every query, every answer, one communication per exchange. It does this without a proxy, without a sidecar and without touching the client or the server.

This post explains how.

"It's always DNS." Everyone running Kubernetes has said it, usually after an hour spent on the wrong suspect. A pod that takes five seconds to start talking to its database. A SERVFAIL that only happens on one node. A service that resolves fine from your laptop and not from the cluster.

The problem is rarely that DNS is complicated. It is that nobody sees it. Until now, Spider didn't either: it showed the HTTP call that came after the lookup, never the lookup itself.

That changes. Spider now decodes DNS from the wire and turns every question into one communication - over UDP, over TCP and over DNS-over-TLS.

Spider has always been a TCP machine. Every parser, every queue, every gating checkpoint in the pipeline starts from the same object: a session, with a beginning, an end, and bytes in order in between.

UDP has none of that. No handshake, no close, no sequence numbers - just datagrams, each on its own. So before Spider could parse a single DNS query, it had to answer a more basic question: what is a session when there is no connection? 🤔

Your AI agents talk to tools over MCP (Model Context Protocol), and on the wire every one of those calls looks the same: POST /mcp 200. Which tool did the agent call? Did it work? Was it a tools/call at all, or a handshake? A tool that failed is, most of the time, an HTTP 200 carrying isError: true - invisible to every HTTP-level view you have.

Spider now reads MCP (Streamable HTTP transport) and describes each message: what was asked, and how it ended.

Every GraphQL call behind /graphql used to look the same to Spider: one HTTP request, one endpoint, one template. POST /graphql 200 three times in a row told you nothing about what actually happened - a mutation that created an order, a query that half-failed, a query a client had no business making.

That is fixed. Each request now carries its real operation and its real outcome, with nothing to instrument and no line of application code to change - and so does every message of a long-lived subscription over WebSocket or SSE.

This version introduces:

• New protocols and streams - MySQL parsing (TLS included), HTTP/2, and Server-Sent Events and WebSocket parsed as one communication per message, all served by a single web-parser.
• Kubernetes workload identity - every capture carries the workloads behind both endpoints, to filter, group and chart by workload, namespace or node, plus TCP/UDP transport on network usage.
• Integrations - com export to CSV across protocols, OTLP metrics export, and a remote MCP server with an OAuth 2.1 server for AI agents.
• Hardening and fixes - stricter access control on reads and public links, and more reliable parsing of split frames and lost capture bytes.

Every statement, every bound parameter, every result row, every error - decoded from the wire, without a proxy, without a slow-query log, without touching the application.

After HTTP, PostgreSQL, Redis, gRPC and Kafka, the next protocol natively decoded by Spider Analyzer is MySQL.

Spider now runs a remote MCP server.
Paste one URL into Claude, ChatGPT or Claude Code, approve a consent screen, and the agent can search, aggregate and inspect the traffic Spider captured - as you, with your rights, and nothing more.

Behind it, Spider became an OAuth 2.1 authorization server, and Network-View gained the screens an operator needs to decide which agent platforms may connect.