ngrok config editwill now allow you to edit an invalid configuration file.
ngrok config editcommand to open the config file in your default editor.
--proxy-protoflag from the
ngrok config upgradecommand to convert basic auth config parameters.
For more information about upgrading from previous versions of the agent to v3.0, see our upgrade guide.
ngrok completionto enable autocomplete for the cli.
proxy_protooption for enabling and specifying the HAProxy's PROXY protocol version.
connect_interfacefor the agent.
ngrok diagnosecommand to the agent for troubleshooting connection issues.
ngrok configcommand for managing the configuration file.
ngrok servicecommand to manage the ngrok agent as a service.
ngrok authtokenwould make changes to your tunnel definitions.
--host-header rewriteoption puts the original host header value into the
X-Forwarded-Hostheader field instead of the
X-Original-Hostheader in an attempt to be more standard.
socks5_proxyconfiguration options into a single option (
If asked to forward to port 443, ngrok will now automatically forward
HTTPS traffic instead of HTTP. This change would only affect you if you
previously ran a server accepting unencrypted HTTP on port 443. To
workaround this, you may specify an explicit http URL if you need the old
ngrok http http://localhost:443.
If run under sudo, the ngrok agent previously consulted the sudo-ing
user's home directory file when looking for its default configuration
file. It now consults the home directory of the assumed user. To
workaround this, you may specify an explicit configuration file location
The ngrok agent API no longer accepts
application/x-www-form-urlencoded request bodies. In
practice, this only affects the
/api/requests/http/:id endpoint because posting to the
/api/tunnels endpoint with this type of request body
previously caused ngrok to crash.
This change was made to help protect against maliciously crafted web pages that could cause a user to inadvertently interact with their local ngrok API.
Behavior changes for
defined in the configuration file or started via the API that do not have
tunnels: webapp: proto: http addr: 80
Given this example tunnel configuration, behavior will change in the following ways.
Starts a tunnel using the name of the tunnel as the subdomain resulting in
Starts a tunnel with a random subdomain, for example a URL like
subdomain property with the same name as the tunnel:
tunnels: webapp: proto: http addr: 80 subdomain: webapp
This behavior changed in order to make it possible to launch tunnels with random domains. This was preventing the use of the configuration file and agent API to free tier users.