Inspect HTTP traffic in DevProxy: requests, responses and webhooks

A webhook was sent, but your app did nothing. Or a website opens through its public address while an API call fails. The DevProxy local panel shows incoming HTTP requests and the application's responses, including headers, bodies, status and duration. You can inspect the exchange without adding logging to the handler.

Open the panel address printed by the running client, usually http://127.0.0.1:4040, on that same computer. Select HTTP traffic. This panel is separate from the website Dashboard. The instructions below describe client 1.0.11.

The screenshots below show the actual local panel in client 1.0.11. A local test receiver handles sample events; the example uses no live provider account.

Prepare an HTTP channel

You need the DevProxy client, an access key created for Website or API, and a working local website or webhook handler. See Getting started if the client is not configured yet.

For an application listening at http://127.0.0.1:3000, a new, separate configuration can contain:

server: https://control.devtunnels.ru
token: YOUR_ACCESS_KEY
reconnect: true

tunnels:
  - kind: http
    name: inspect-demo
    local: http://127.0.0.1:3000

Replace the key and local address. Preserve other channels in an existing configuration. If this application already has a channel, use that one instead of creating another.

For a Windows ZIP, open PowerShell in the extracted folder and run .\devproxy.exe start. For an extracted Linux/macOS archive, use ./devproxy start. After installation into PATH, use devproxy start. Add --file "full path to the file" for a separate configuration.

Open the local panel. In client 1.0.11, panel access protection is optional in settings. If enabled, obtain a one-time code on the same computer as the user running the client: .\devproxy.exe panel code, ./devproxy panel code or devproxy panel code, depending on installation. When several clients run, select the intended one with --instance <PID>. Use the actual panel address printed by the client; its port can differ when 4040 is busy.

Find the request and response

Copy the channel's public HTTPS address from Dashboard Tunnels and open it. For a webhook, send an event from your test service. A request made directly to localhost bypasses the tunnel and will not appear here.

Start with the list on the left. Service names the channel, Method shows GET or POST, Path identifies the route and Status shows the HTTP result. In this example, the receiver answered the health check and webhook with 200, while a request to the wrong route returned 404.

Choose the channel in All services, keep the relevant method such as POST, and find the path using Search requests. Select the POST /webhook/preview row to open its details on the right:

• Request headers and Request body show what the incoming request contained.
• Response headers and Response body show the application's reply.
• The status and duration help distinguish rejection from a slow response.

In Request body, the test event has event_id: demo-001 and a message. Response body contains received: true and handled_count: 1, returned by this test receiver. These are fields of the example application, not values added by DevProxy.

Use Beautify beside each body to format its JSON, as shown above. For a webhook, compare its path, content type and event fields with what the handler expects. A 401 or 403 indicates an access refusal; a 404 can reveal the wrong route. A 200 response confirms an HTTP reply, but does not prove that a business action succeeded. Check the outcome in the application too.

Replay a request after a fix

Replay sends the recorded request directly to the local application. On a test handler, change the code, replay the request and inspect the new response next to the original. Replay does not contact the webhook sender or check the full public delivery path.

Read the Replay response 200 box above the original exchange. The test receiver now returns handled_count: 2: it handled the same event again. The original response below still describes the first request.

The handler actually runs again. Creating an order, sending an email or changing data may happen twice. Use test events and the application's duplicate handling. Requests with a truncated body cannot be replayed.

Export the session and understand its limits

Export HAR downloads the current HTTP exchange history. Clear history removes it. History belongs to the current client run, so export anything you need before stopping the client. Headers, bodies and HAR files may contain cookies, webhook secrets and user data. Remove these before sharing.

The monitor keeps up to 1000 recent records and captures up to 256 KiB for each request and response body. Larger bodies are marked as truncated. Requests with selected file extensions, including .js, .css and image extensions, are skipped. This is not a complete archive of every website request.

The view covers HTTP exchanges through this client. It does not decode arbitrary TCP traffic, RDP, or messages inside a WebSocket connection after the upgrade.

If the list is empty

• Open the panel of the client serving that channel. Another computer's panel has a different history.
• Make sure the channel is running and visit its public address rather than the local application directly.
• Clear the search and method filters and select All services. Try a page or API route without a static file extension.
• For a 502, check that the address in local opens on the client's computer. A missing record does not prove the sender made no attempt; delivery may have been rejected earlier.

For a specific delivery, follow the GitHub webhook guide. The monitor explains the HTTP exchange; the sender's delivery log shows when and how it attempted delivery.