I use both, Traefik on my docker host that’s also used for trying out new stacks, and NPM at work for a config that won’t change (ever, probably).

Yes, the NPM web ui is somewhat easier in regard to proxying targets outside Docker.

I use the caddy plugin in opnsense. Used nginx proxy manager from Proxmox helper scripts before that, which was relatively easy and helped me understand the whole proxy thing. Moved to caddy on opnsense a few months ago, just because, and have had no good reason to change yet.

I use nginx as the internet facing proxy, write my own config and manage it with source control. Also use traefik in docker land with service labels to configure it

In my experience, all the 3 big ones work just fine. Caddy, Traefik, Nginx. I use Nginx.

I want to just mention frp, I use it to get around firewalls

Nginx installed directly, I use nano over ssh to edit configs. Forces you to learn some things and I never moved passed it because it works so well.

I’ve been using NPM for a few years now and can’t recommend it enough. I use it to route to both docker containers on an internal proxy network as well at other services within my networks

This the main reason I switched from traefik, I can have certificates on all my internal stuff and not just on my docker host. I personally love NPM but maybe I’ll give NPMPlus a try, I have never heard of it.

If you’re just going to VPN in to your home network, I’ve found caddy to be the simplest.

Nginx from day one. Well documented, it works. If something doesn’t work chances are you are a quick googlefu away from the solution.

I’ve been using nginx forever. It works, I can do almost everything I want, even if more complex things sometimes require some contortions. I’m not sure I would pick it again if starting from scratch, but I have no problems that are worth switching for.

I used NPM, It was pretty solid

Then I changed headspace and now I run SearXNG through cloudflare, and tailscale everything that doesn’t need to be public.

Traefik is a PITA.

Caddy all the way. If you build it with Docker support (or grab the prebuilt), you can use docker container names to reverse proxy using names instead of any IP addresses or ports. It’s nice because if the IP updates, so does caddy. All automatically.

Here’s what my caddyfile looks like;

{
        acme_dns cloudflare {key}
}

domain.dev {
        encode zstd gzip
        root * /var/www/html/domain.dev/
        php_fastcgi unix//run/php/php8.1-fpm.sock
        tls {
                dns cloudflare {key}
        }
}
*.domain.dev {
        encode zstd gzip
        tls {
                dns cloudflare {key}
        }
        @docker host docker.domain.dev
        handle @docker {
                encode zstd gzip
                reverse_proxy {portainer}
        }
        @test host test.domain.dev
        handle @test {
                encode zstd gzip
                reverse_proxy 127.0.0.1:10000
        }
        @images host i.domain.dev
        handle @images {
                encode zstd gzip
                reverse_proxy 127.0.0.1:9002
        }
        @proxy host proxy.domain.dev
        handle @proxy {
                encode zstd gzip
                reverse_proxy proxy
        }
        @portal host portal.domain.dev
        handle @portal {
                encode zstd gzip
                reverse_proxy portal
        }
        @ping host ping.domain.dev
        handle @ping {
                encode zstd gzip
                respond "pong!"
        }
}

DNS hosted by cloudflare but because caddy handles ACME certs, all the subdomains automatically get SSL.

Caddy is the only reverse proxy I have ever managed to successfully make use of. I failed miserably with Nginix and Traefik.

Caddy has worked very well for me for several years now. It gets the SSL certificate from my domain name provider and all.

having tried many in past, i always go back to haproxy. it has everything required as proxy and load balancer while also being very efficient.