Some advanced options to allow CORS preflight requests bypass authentication, add X-Forwarded headers, etc.
By default, trying to connect to establish a tunnel with a token which is already in use by another active tunnel will produce the error “Login is not allowed: A tunnel with the same token (xxYYzzZ) is already active.”
In such cases, in order to terminate the tunnel, you can use the “Terminate” option in “Active Tunnels” page in https://dashboard.pinggy.io/
If you want to programatically disconnect an existing tunnel to forcefully create a new one, you may use the force
option as follows.
By default Pinggy acts as a reverse proxy for HTTP(S) tunnels. This means it adds X-Forwarded-For
, X-Forwarded-Proto
, X-Forwarded-Host
, and Forwarded
headers in the http requests.
To disable reverse proxy mode, pass the argument x:noreverseproxy
, and Pinggy will not add these headers.
X-Forwarded-For
is a mechanism to finding out the source (IP and Port) of the connection. If you turn of reverse proxy mode, Pinggy HTTP(S) tunnel does not implicitly add the this flag. However, user can enable X-Forwarded-For
header with x:xff
command line argument.
If you want to change the header name from X-Forwarded-For
to something custom such as Source-Address
, you can also do so using the argument: x:xff:Source-Address
.
Some servers do not respond correctly if the Host header value does not match its expected value. Pinggy by default keeps the Host header unchanged, and its value will usually be the Pinggy subdomain, or the custom domain configured by you. To modify the Host header, use the u:Host:<host>
argument. For example:
Read more about live header modification.
By default, enabling key authentication / password authentication will block all unauthenticated requests to Pinggy URLs. But sometimes the CORS preflight requests are required to be sent through to enable CORS. In those cases you can use the x:passpreflight
argument.
Pinggy allows users to manipulate headers via the command line. The syntax is as follows: