> ## Documentation Index
> Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connections

> How a request from a Network reaches a host behind the tunnel, step by step.

A function on the [*Network*](https://developers.telnyx.com/docs/network/overview.md) `acme-prod` connects to `10.20.3.7:8080`, an address that a route sends to the tunnel `chicago-dc`. The diagram follows that one request:

The diagram shows four parties side by side: the function, Telnyx, the
tunnel process on `dc1-tunnel-a`, and the web service at `10.20.3.7:8080`.
The six steps below run between them, and a bar at the bottom shows the
three parts of the flow: connection A, the stream, and connection B.

1. The tunnel process opens an outbound TLS connection to Telnyx and sends its token. Telnyx checks the token and confirms on the first stream of the connection. The process then waits. It opens nothing else toward Telnyx.
2. The function opens TCP connection A to `10.20.3.7:8080`. The route on `acme-prod` brings A to Telnyx, which terminates it.
3. Telnyx opens a new stream on the connection of one tunnel process and sends a connect request. The request names the protocol, the destination address and port, the *Network*, and the client's address. It is a message on a stream, not a packet. Nothing is encapsulated, and no route is exchanged.
4. The process dials `10.20.3.7:8080` from its own host. Connection B is an ordinary connection from the tunnel host, so the destination needs no route to Telnyx and sees the tunnel host as the source.
5. The process answers `ok`, or refuses. A refusal resets A, and the function's request fails with a reset connection.
6. Bytes then flow across A, the stream, and B until either side closes.

A and B are network connections. The stream between them relays bytes and is not a connection to anything. No packet from the function crosses the tunnel. For the same reason, hosts behind the tunnel cannot start connections through it, and a stream that the tunnel process opens toward Telnyx goes nowhere.

The process stores no configuration. Routes, [private services](https://developers.telnyx.com/docs/network/tunnel/features/private-services.md) Preview, and [public hostnames](https://developers.telnyx.com/docs/network/tunnel/features/public-hostnames.md) Preview live in Telnyx, and Telnyx asks the process to dial only the destinations that they declare.

## One Connect Request per Flow

Each flow reaches a tunnel process as its own connect request, which names one destination. The process dials that destination and nothing else. Each flow is placed on its own as well. With two tunnel processes connected, three requests from the function reach the web service as three connections, from the two tunnel hosts in turn:

```text 10.20.3.7 access log theme={null}
10.20.0.11 - - "GET /n1 HTTP/1.1" 200 -
10.20.0.10 - - "GET /n2 HTTP/1.1" 200 -
10.20.0.11 - - "GET /n3 HTTP/1.1" 200 -
```

By default the tunnel process logs nothing for a flow. With `-v`, it logs each flow that it relays, and each destination that refuses a connection:

```bash Tunnel host theme={null}
telnyx-edge -v tunnel run --token tnl_…
```

```text Output theme={null}
{"time":"2026-10-26T14:27:44.768359757Z","level":"DEBUG","msg":"tunnel: relaying","dest":"10.20.3.7:8080","caller":"172.27.0.2:53840","network":"d8a7e0b1-2d64-4d62-aeb2-b77465835059"}
{"time":"2026-10-26T14:28:17.99189773Z","level":"INFO","msg":"tunnel: dial failed","dest":"10.20.3.7:9999","error":"dial tcp 10.20.3.7:9999: connect: connection refused"}
```