Secure Debugger

Perfecting Rules with Secure Debugger

Enabling the Debugger

Our SANDBOX allows you to see requests/responses through the proxy in real time to debug your rules, see how they interact with the proxy before you move to a LIVE (production) vault.
Once in the Logs area, click the button to enable logging. This enables logging for 2 minutes for the vault you are testing rules in.

Viewing Reverse Proxy Traffic

Copy your curl from the integration tab and run in terminal. reverse-proxy-curl

Pay attention to the Vgs-request-id field in the headers from the response, this will help you locate your log quickly. reverse-proxy-response

Go back to your logging window and check the results search-debug-logs
There are four logs. We have the raw request and response and the rewritten request and response. This is because VGS Proxy works both on request and response.

We see the 200 response which is a good sign. To see the actual transformation expand the raw request and rewritten request. expand-request-raw-debug-logs As you can see the raw request, from our curl, was “foo”, the VGS reverse proxy replaced that with a surrogate value “tok_SANDBOX_…”

Viewing Forward Proxy Traffic

At this point you may need to enable logging again. Do so and test out the forward proxy curl. Copy it from integrations and put in the token as payload that you got from your reverse proxy curl. forward-proxy-curl

Now you’ll have more logs (from two requests) so you can use the vgs-request-id to filter down again. forward-proxy-response

Filtering down we see 200s again and you’ll see logs identical to reverse proxy. search-debug-logs

Expanded we see that it did re-write the request and replace the original value (what would be your sensitive data) back into the payload. search-debug-logs-forward


If you send data and an error occurs, the secure debugger is extremely useful. In the screenshot there’s a simple error, a 405. 405

If we expand the response we can see the exact nature. error-expanded This particular endpoint only allows for HEAD, OPTIONS, GET. Our request (which you can see in the previous screenshot) was a post to a /get route.
Our Secure Debugger shows the body of the payloads, the response messages and is useful for making sure headers, end-points, paths, etc. align with the rules set up.


  • 407s may occur before the response on forward proxy as it requires authorization you may get that back on your server.
  • If you only see a request and no response, it may mean that your request didn’t complete its tunnel through the proxy.
  • If you don’t see anything on the logs, you’re not hitting the proxy at all (if logging is enabled, of course).
  • This also allows you to see what your server will receive (on reverse proxy side) or what third parties will see when testing the forward proxy.

If you have any questions, comments or feedback on this guide contact us on Intercom or at