gRPC, GraphQL and Protobuf

gRPC and GraphQL both answer 200 OK and report failure somewhere else. A proxy that stops at the HTTP status tells you every call succeeded. WireLens reads where these protocols actually put the outcome.

gRPC#

• Trailers are kept. gRPC puts its verdict in grpc-status and grpc-message trailers. WireLens captures them, forwards them to the client untouched, and shows the gRPC status on the flow, so a failed call is visibly failed even though HTTP said 200.
• Streaming works. Client-streaming and bidirectional calls are relayed as they arrive instead of being buffered, so they do not hang. The trade-off: a request body that is still streaming cannot be mocked, rewritten or paused, because it has not ended yet. Responses still can.
• gRPC-Web and Trailers-Only responses are understood too, including a status carried in the headers.
• HTTP/2 upstream. gRPC needs HTTP/2 end to end, and WireLens speaks it to the server.

The gRPC filter chip shows every call, and operation: in the search box finds a method by name, such as operation:GetStock.

GraphQL#

Every GraphQL request is POST /graphql, so a plain traffic list shows a column of identical rows. WireLens reads the operation instead:

• The operation name appears on the flow, and operation:CheckoutMutation finds it.
• An errors array in a 200 response is flagged as the failure it is.
• Batches, persisted queries, GET ?query= requests, and subscriptions over graphql-ws and the older subscriptions-transport-ws are all recognised.

Protobuf#

Protobuf bodies decode without any setup: WireLens reads the wire format and shows field numbers and values, telling text from nested messages as it goes.

For names instead of numbers, import your descriptors in Settings ▸ Protobuf. gRPC and Protobuf bodies then show the field names from your schema. The MCP tool set_protobuf_schema does the same from an agent.

Decryption#

All of this happens on decrypted traffic, so the host must be on the SSL Proxying Include list. See SSL Proxying.