Skip to main content
The HTTP tab in Traffic Inspector lists the HTTP and HTTPS requests to your endpoints. When you enable full capture mode, you can replay requests to your upstream directly from the browser, instead of the original source. This can dramatically speed up development of webhooks or callbacks that are difficult to trigger repeatedly. To see the connection a request traveled over, open the request’s Connection tab. See Connections and requests.

​
Full capture mode

By default, the ngrok Traffic Inspector only stores the metadata about each request and response. Full Capture mode is an opt-in setting on your ngrok account that stores the full request and response parameters, headers, and bodies for each traffic event that flows through your endpoints. Account admins can enable it by visiting the Observability section in the ngrok Settings Page after logging in.
Storing the full request and response data may mean you and your team members have access to sensitive data flowing through your endpoints.
After you enable full capture mode, ngrok begins capturing and storing the full requests and responses up to a maximum of 10KB, after which ngrok truncates the data. ngrok truncates each header value after 1KB. Traffic Inspector indicates truncated data through the number of bytes captured as well as the number of headers. ngrok stores this data for your account’s retention period (24 hours for Free, 72 hours for Hobbyist and Pay-as-you-go) from the time it receives a request.

​
Replay

Replaying requests lets you re-send an HTTP request upstream without directly accessing the endpoint. To use replay, you must activate Full Capture mode in your account. After you enable Full Capture, a replay button appears for fully captured requests in the traffic event details pane of the dashboard. If this button is unavailable, it likely indicates that the request occurred before Full Capture was fully activated, or the request was too large and has been truncated. Replay works by resending your original unmodified request to your endpoint. It’s subject to the policies of that endpoint at the time of replay (which could be different than the original request). When you replay a request to your service, ngrok makes minimal changes. However, some alterations are inevitable. Here’s a list of changes made to replayed requests:
  • The replayed request originates from a different IP address, so any IP restrictions may prevent the replay from reaching your upstream.
  • ngrok removes any Connection: Keep-Alive headers because replay doesn’t support them.
  • Some request bodies might not be captured, even if they were replayed successfully. This is particularly true for traffic events with an error status code.
  • ngrok adds a custom header Ngrok-Replay-Original-Request-ID that contains the ID of the original request. This lets you trace back to the original request if needed.
  • If the request has been truncated, you can’t replay it.
  • You can’t replay the request if the HTTP method is unknown or undefined.
  • ngrok substitutes the X-forwarded header values with accurate values for the replay, not the original request.

​
Replay with modifications

ngrok Traffic Inspector lets you edit the request before re-sending it to your backend. You can access it from the same dropdown as Replay. ngrok makes the same changes to the replayed requests as before, in addition to the following changes:
  • You can’t modify any forbidden headers in the replayed request.
  • You can replay the request to the same endpoint as long as it’s in the same account. You can’t replay to endpoints that are active in other accounts.
  • ngrok doesn’t support modifying the trailer of the request. If you need that capability, share feedback in the ngrok Community Repo.