Adding a fd that is not obtained through accept to the list the active connections

Ottavio Campana ottavio at
Tue Aug 31 19:18:33 UTC 2021

Dear Phillip,

an ssh tunnel is not compatible with the specs of the ONVIF uplink service.

I understand that there is no "free lunch" to achieve this, thus I expect
to have to write code. What is the suggested way to add a connection, by
passing the fd of the connection to nginx before establishing the SSL
context. Where could I hook up? How can I implement a fake listener that
does not listen but connects to a remote server?

Thank you,


Il giorno lun 30 ago 2021 alle ore 13:24 Phillip Odam <
phillip.odam at> ha scritto:

> Hi Ottavio
> There’s no solution just with nginx as it currently that I know of, to
> avoid the need for a port forward in the NAT router a simple solution would
> be to use a ssh tunnel - this does separate initial connection from
> subsequent requests as you’re unlikely to want to establish a new tunnel
> for each and every request and ‘knowledge’ the connection is established is
> no longer inherently part of the application making the HHTP request. So to
> simplify things you could just expect the ssh tunnel to be established as a
> precondition (once off initial setup)
> Phillip
> On Friday, August 27, 2021, Maxim Dounin <mdounin at> wrote:
>> Hello!
>> On Fri, Aug 27, 2021 at 01:59:03PM +0200, Ottavio Campana wrote:
>> > Dear Phillip,
>> >
>> > I know Tailscale very well, I use it and like it a lot. But my final
>> goal
>> > is finding a way to implement the ONVIF Uplink service,
>> > , where I
>> can
>> > have several devices on the LAN that need to connect to a remote server,
>> > which will then send commands.
>> >
>> > Therefore I need a way to start a connection from nginx (or an external
>> > program and then passing the fd through a unix socket domain) and make
>> it
>> > act as if the fd were obtained from an accept.
>> >
>> > Nginx works with events and I find it very difficult to find a
>> mechanism to
>> > pass this connection to it.
>> >
>> > Do you have other ideas?
>> The most simple solution I can think of is to open two
>> connections: to your command endpoint and to nginx, and proxy
>> everything once the connections are established.
>> --
>> Maxim Dounin
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at

Non c'è più forza nella normalità, c'è solo monotonia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx-devel mailing list