> For the complete documentation index, see [llms.txt](https://docs.remote.it/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.remote.it/features/connection-options/peer-2-peer-and-proxy.md).

# Peer-2-Peer & Proxy

Remote.It connection types — direct and relayed peer-to-peer, and private, public and reverse proxy — how each is routed, who can use it, and how long it lasts.

A Remote.It connection links an **initiator** (the device or app you connect from) to a **target** (the device and service you connect to). There are two connection types, **peer-to-peer (P2P)** and **proxy**. Each has sub types that change how the connection is routed, who can use it, and how long it lasts.

The type you get depends on the client you use and on current network conditions:

| Client     | Peer-to-peer | Proxy |
| ---------- | :----------: | :---: |
| Desktop    |       ✓      |   ✓   |
| CLI        |       ✓      |   ✓   |
| Mobile     |       ✓      |   ✓   |
| Web Portal |              |   ✓   |
| API        |              |   ✓   |

The Desktop, CLI and mobile apps try P2P first by default and fall back automatically if needed. The Web Portal and the API make proxy connections only.

The key difference between the two types is what Remote.It does with your traffic. In a P2P connection, Remote.It never terminates or inspects your data. In a proxy connection, a Remote.It proxy server terminates the incoming connection and opens a separate connection to the target.

## Peer-to-peer (P2P) connections

P2P connections are supported in the Desktop app, CLI and mobile apps. They give you a persistent, repeatable address, since the connection URL resolves to `localhost` on the initiator with an assigned port. You can bookmark it, and Remote.It will reconnect on demand when the connection is used again. P2P connections have no time limit and are usually faster than proxy connections. Because the address is local to the initiator's computer, a P2P connection cannot be shared with other people.

### Direct P2P

Traffic travels straight between the initiator and the target, with no Remote.It server in the data path. This is the ideal case. It isn't always possible, particularly when a device is behind restrictive NATs or firewalls, or is on a cellular modem. If you set Routing to **Peer to peer only**, Remote.It attempts only this kind of connection and will not fall back to a relayed path.

### P2P with relayed (websocket) fallback

When a direct connection can't be established, Remote.It falls back to a websocket connection that passes through a Remote.It server. This is still treated as peer-to-peer because the server acts only as a pass-through relay. It does not decrypt the traffic, does not convert it into a separate TCP connection to the target, and does not alter the data. The websocket simply carries the data along between the two endpoints. Your connection keeps the behavior of a P2P connection — persistent `localhost` address, no expiry, not shareable — even though the data path now includes a Remote.It server.

### Routing settings

You control which of these behaviors you get with the **Routing** setting on a connection:

| Routing setting                            | Behavior                                                                                                      |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| Peer to peer with proxy failover (default) | Tries P2P first, including the relayed fallback, then rolls over to a proxy connection if P2P isn't possible. |
| Peer to peer only                          | Attempts P2P only. If it can't be established, the connection fails.                                          |
| Proxy only                                 | Skips P2P and makes a proxy connection. Try this if P2P doesn't work in your environment.                     |

To get a connection that never expires, use the Desktop app, set Routing to **Peer to peer only** and set the timeout to **0**.

{% hint style="info" %}
UDP services must use peer-to-peer. If peer-to-peer won't connect, for example on some cellular networks, try **Proxy only**.
{% endhint %}

## Proxy connections

In a proxy connection, all traffic is routed through a Remote.It proxy server. The proxy server terminates the incoming connection (for example, HTTPS), decrypts it and opens a separate TCP connection to the target. This is what makes proxy connections work in nearly any network condition, and it is also why they behave differently from P2P:

* Each connection gets a temporary address that changes every time you connect.
* Connections expire. A proxy stays active for up to about 8 hours while a tunnel is maintained, and expires after about 15 minutes of inactivity.
* They can be shared with others, using the sub types below.

The Web Portal and API always create proxy connections. If you use the API, your application must detect expiration and establish a new connection when needed.

### Private proxy

The standard proxy connection, intended for your own use. You connect to a host and port on a Remote.It proxy server, which passes traffic to your target. The address is issued to you when you connect and expires with the session. Use it when P2P isn't possible and you don't need to share access.

### Public proxy

A proxy connection you can share with someone else. It creates a shareable address that is valid for a limited time, typically hours. Anyone who has the connection URL and port can connect until it expires or is closed, so make sure the resources behind it are properly password protected. Choose a security mode when you create it:

| Security mode  | Behavior                                                                                                                                |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| IP restriction | Only connections from the specified public IP address or range are allowed. All others are blocked.                                     |
| IP latching    | The connection latches to the first IP address that connects after the proxy is created and blocks all others, wherever they originate. |
| None           | Connections are accepted from any IP address.                                                                                           |

### Reverse proxy (HTTP/HTTPS services)

For web services, Remote.It can generate a randomized URL that you open in a browser, with nothing to install on the initiator. Reverse proxies are always public, which is why the randomized URL is created. Web connection proxies expire about 15 minutes after the last web request, so you may need to refresh or navigate to reconnect. This is convenient for quick browser access to something like a device's admin page.

## Choosing a connection type

| If you need...                                                    | Use                                                          |
| ----------------------------------------------------------------- | ------------------------------------------------------------ |
| A persistent, repeatable address for your own use, with no expiry | P2P (Desktop, CLI or Mobile)                                 |
| The best chance of connecting in any network                      | P2P with proxy failover (the default)                        |
| Access when P2P won't work in your environment                    | Proxy only (private proxy)                                   |
| To give someone else temporary access                             | Public proxy, with IP restriction or latching where possible |
| Quick browser access to a web service with nothing installed      | Reverse proxy                                                |
| To connect from the Web Portal or API                             | Proxy (the only option)                                      |

## Summary of connection types

| Type  | Sub type                     | Data path                                          | Persistent address | Shareable    | Expires                 |
| ----- | ---------------------------- | -------------------------------------------------- | ------------------ | ------------ | ----------------------- |
| P2P   | Direct                       | Initiator to target                                | Yes (`localhost`)  | No           | No                      |
| P2P   | Relayed fallback (websocket) | Passes through Remote.It, not decrypted or altered | Yes (`localhost`)  | No           | No                      |
| Proxy | Private                      | Terminated at a Remote.It proxy server             | No                 | No           | Yes                     |
| Proxy | Public                       | Terminated at a Remote.It proxy server             | No                 | Yes          | Yes                     |
| Proxy | Reverse (HTTP/S)             | Terminated at a Remote.It proxy server             | No (random URL)    | Yes (public) | Yes (about 15 min idle) |

For more detail, see [Peer to Peer vs Proxy Connections](https://support.remote.it/hc/en-us/articles/360044788252-Peer-to-Peer-vs-Proxy-Connections) in the support center.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.remote.it/features/connection-options/peer-2-peer-and-proxy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.