Proxy & TLS

Vegha gives you control over how requests reach the network and how TLS connections are established — useful behind corporate proxies or when testing against internal services with non-public certificates.

System proxy

By default, Vegha can use your operating system’s proxy settings, so requests follow the same routing as the rest of your machine. This requires no configuration when your environment is already set up at the OS level.

Custom proxy

When you need a different route — for example to send traffic through an intercepting proxy for debugging — you can configure a custom proxy in Vegha instead of relying on the system settings. Requests are then sent through the proxy you specify.

Mode	Behavior
System proxy	Uses the operating system’s proxy configuration
Custom proxy	Routes requests through a proxy you configure in Vegha

Trusting custom certificates

TLS connections are verified against trusted certificate authorities. When you test against a server whose certificate is not signed by a public CA — such as an internal service or a development environment — you can supply a custom CA certificate so Vegha trusts that chain. This lets you connect to self-signed or privately-signed endpoints without disabling verification globally.

TLS client certificates (mTLS)

Some services require the client to present a certificate as well — mutual TLS. Vegha lets you supply a TLS client certificate at the request level, so the certificate is presented during the TLS handshake when that request connects.

This request-level mTLS configuration covers the connection itself. For the full reference on mutual TLS as an authentication method — including how it interacts with the Authorization tab — see mTLS authentication.

Seeing the effect

Proxy and TLS settings influence the connection timeline shown in the response viewer. If a proxy or a TLS handshake is adding latency, the Connect and TLS phases make it visible — see Responses.