# https://tunnels.io/learn/http-vs-https-tunnels

[Home](https://tunnels.io/) / [Learn](https://tunnels.io/learn) / HTTP vs HTTPS tunnels

Learn

# HTTP vs HTTPS tunnels: which do you need?

You need HTTPS, and on a modern tunnel service you get it without asking. What actually differs is where TLS ends. The tunnel edge holds the certificate and decrypts the request there, then forwards plain HTTP to your local app. Your app stays HTTP; the public URL stays HTTPS.

## What is the difference between an HTTP and an HTTPS tunnel?

An HTTPS tunnel publishes a URL that starts with `https://`` and presents a certificate for that hostname to anyone who connects, so the request is encrypted and authenticated before it leaves the visitor's machine. An HTTP tunnel publishes a plain `http://`` URL, which means every network between the visitor and the edge can read the request and change the response. The local side is identical in both cases: your server keeps listening on a plain port. The only thing that changes is what the public internet sees.

Confusingly, "HTTP tunnel" also has an older and completely unrelated meaning: tunneling arbitrary traffic through a forward proxy with the CONNECT method. That is covered further down, because it is a different direction of travel and solves a different problem.

## Where does TLS get terminated?

At the provider's edge server, not on your machine. The edge owns the certificate for the public hostname, so it is the only party that can complete the handshake, which means it must decrypt the request in order to route it. From there the request travels to the tunnel client over the connection the client already opened outbound, and the client hands it to your local port as ordinary HTTP.

That is three separate hops, and it is worth knowing which of them are encrypted:

| Hop | What carries it | Encrypted |
| --- | --- | --- |
| Visitor to edge | The public internet, port 443 | Yes, TLS with a publicly trusted certificate |
| Edge to your machine | The outbound connection the tunnel client opened | Yes, TLS again, initiated from your side |
| Client to your server | Loopback, for example http://localhost:3000 | No, and it does not need to be |

The only plaintext hop is the one inside your own computer. Nothing on the public internet ever sees an unencrypted byte.

## Do I need HTTPS for local development?

For browsing your own app at `http://localhost``, no. Browsers treat localhost as a secure context, so service workers, geolocation, camera and microphone access, and the Web Crypto API all work there over plain HTTP. That exemption is tied to the loopback address specifically, not to development in general.

The moment your app is reached at a public hostname, the exemption is gone. Those APIs go silent, cookies marked `Secure`` are not stored, `SameSite=None`` stops working, and an HTTPS page will refuse to load any `http://`` subresource it references. A tunnel gives you a real HTTPS origin without generating a local certificate or persuading your operating system to trust it.

## Why do webhook providers require HTTPS?

A webhook is an unsolicited POST carrying data you did not ask for at that moment, sent to a URL that is often the only thing standing between the internet and your business logic. Over plain HTTP, every hop between the provider and you can read the payload, and anyone who can inject packets can forge one. Signing headers help, but they do not help if the request never reaches you intact.

So most providers simply refuse an `http://`` endpoint at registration time, and the ones that still allow it usually restrict it to test mode. This is the single most common reason developers go looking for a tunnel in the first place. There is more detail in [how to test webhooks locally](https://tunnels.io/learn/how-to-test-webhooks-locally).

## What is the CONNECT method?

CONNECT is the HTTP method a client uses to ask a forward proxy to open a raw TCP connection to a host and port and then relay bytes in both directions without interpreting them. It is how a browser reaches an HTTPS site through a corporate proxy: the proxy answers with 200, and the TLS handshake then runs end to end through it, so the proxy moves ciphertext it cannot read. This is the original meaning of the phrase "HTTP tunnel".

It points the opposite way from the tunnel you are probably shopping for. CONNECT gets your outbound traffic through a proxy that stands in front of you; a reverse tunnel gets inbound traffic to a machine that has no public address at all. The two do coexist: if your network forces all outbound traffic through a proxy, a tunnel client can use CONNECT to reach the tunnel server, then run the reverse tunnel inside it.

## Does HTTPS slow the tunnel down?

Not by an amount you will find in a profiler. TLS 1.3 costs one extra round trip to establish a connection and nothing at all when a session resumes, and the bulk encryption runs on dedicated CPU instructions, so throughput is barely affected. In a tunnel, latency is dominated by geography: the visitor reaches the edge, the edge reaches your laptop, your laptop answers, and the whole path runs again in reverse.

Because TLS terminates at the edge, your local server does no cryptographic work for inbound requests at all. Turning HTTPS off, on the services that even let you, would save you nothing measurable and cost you every browser API that requires a secure context.

## What about TCP and other protocols?

HTTP and HTTPS is one of two modes tunnels.io supports. The other is TCP, which forwards raw bytes for things like a database, an SSH daemon or a game server; a TCP tunnel does not terminate TLS, so whatever encryption the service speaks is carried straight through and stays end to end. TCP tunnels are a paid capability, and the free Basic plan is HTTPS only.

There is no UDP mode and no SMTP mode. If your protocol rides on TCP it can go through a TCP tunnel; if it does not, a tunnel is not the tool. For the general picture of what encapsulation is doing here, start with [what is tunneling](https://tunnels.io/learn/what-is-tunneling).

## Related reading

[What is tunneling? The mechanism underneath all of this: wrapping one protocol inside another so traffic crosses a network that would not otherwise carry it.](https://tunnels.io/learn/what-is-tunneling) [How to test webhooks locally Giving a provider a public HTTPS URL that points at your laptop, and verifying signatures once the payloads arrive.](https://tunnels.io/learn/how-to-test-webhooks-locally) [What is a reserved subdomain? Why a URL that changes on every restart quietly breaks every webhook and every certificate assumption built on it.](https://tunnels.io/learn/what-is-a-reserved-subdomain)

Or browse everything in [Learn](https://tunnels.io/learn).

## Questions

### Is an HTTPS tunnel end to end encrypted?

Not in the strict sense. Traffic is encrypted from the visitor to the tunnel edge, decrypted there so the request can be routed, then encrypted again for the trip down to your machine. The only plaintext hop is loopback inside your own computer. If you need bytes that nobody in the middle can read, use a TCP tunnel and let the service speak its own TLS.

### Do I need a TLS certificate on my local server?

No. Your local server can keep listening on plain HTTP, because the tunnel edge presents the certificate for the public hostname. Generating a self-signed certificate for localhost usually creates more problems than it solves, since browsers and webhook senders reject it anyway.

### Why does my page load over the tunnel but the API calls fail?

That is almost always mixed content. The page arrives over HTTPS, and something inside it requests an `http://`` URL, which the browser blocks outright. Hardcoded API base URLs pointing at http://localhost:3000 are the usual culprit; switch them to a relative path so they follow whatever origin served the page.

### Will visitors see a certificate warning on a tunnel URL?

No. Tunnel URLs are served with certificates from a publicly trusted authority, so there is no browser warning and nothing to add as an exception. tunnels.io also shows no interstitial or warning page of its own on any plan, including the free one, so automated callers reach your server directly.

## How does tunnels.io handle TLS?

Every HTTP tunnel gets a public HTTPS URL with a valid certificate, issued and renewed for you. There is no flag to enable it and no configuration to write: you point the client at a local port, TLS terminates at our edge, and plain HTTP is delivered to your app over the connection the client opened outbound to port 443. Custom domains on Gold and Premium get their certificates provisioned and renewed automatically through Let's Encrypt.

The free Basic plan issues a random HTTPS URL, which is fine for a quick share. Pro adds reserved subdomains that survive a restart, plus TCP tunnels when you need a raw byte stream rather than terminated HTTP. The full breakdown is on [pricing](https://tunnels.io/pricing).

[Get started →](https://tunnels.io/get-started) [See pricing](https://tunnels.io/pricing)