xpra icon
Bug tracker and wiki

Opened 4 weeks ago

Last modified 2 weeks ago

#2125 assigned enhancement

let a server register with a proxy

Reported by: brief Owned by: Antoine Martin
Priority: major Milestone: 3.0
Component: network Version: 2.4.x
Keywords: Cc:


If a server has the ability to register on a proxy, the proxy can become aware of servers where discovery via bonjour is not possible.

Furthermore, this allows hole punching in the servers firewall if the server is keeping the connection to the proxy alive. This allows to have client and server behind a NAT and only needs a proxy exposed.

Change History (2)

comment:1 Changed 4 weeks ago by Antoine Martin

Milestone: 2.53.0
Owner: changed from Antoine Martin to brief

How would a client identify which server it wants to connect to?

The standard way of doing this at the moment is using sqlite auth (#1488), which you can already use today as long as the server is not behind NAT: the servers can add themselves to the sqlite auth database used by the proxy to locate sessions for its users.

To workaround the NAT problem, the servers would need to connect to the proxy instead of the other way around.
The connection would have to be authenticated and then kept alive until a client takes over.
This is quite similar to #1022.

comment:2 Changed 2 weeks ago by Antoine Martin

Component: corenetwork
Owner: changed from brief to Antoine Martin
Status: newassigned
Summary: let a server register at a proxylet a server register with a proxy

Add a new command line option so that servers can advertise themselves to remote proxy servers.
This would complement wiki/MulticastDNS and make it easier to deploy proxy servers.
Can also be used for easy NAT traversal: both server and client can be behind NAT.

Related tickets:

  • #1590 network tracker ticket
  • #675 extend xpra proxy for terminal server deployments


xpra start --start=xterm \


  • only allow registration on some tcp / ws / wss / ssh sockets?
  • support multiple proxies: register with all of them, or the first one, or random, or...
  • re-connect to the proxy if the connection drops, maybe add an option to give up and exit if none of the proxies are available for too long
  • keep connection to proxy alive - also similar to #1022: "client listen mode"
  • the proxy needs to keep track of those sessions in memory, return them before or after the ones from the client auth module?
  • the proxy servers could also listen for mdns broadcasts and expose those servers
Note: See TracTickets for help on using tickets.