[jgehrcke]

I want to add that I have learned so much by following the nginx mailing list for more than a decade.

Can we give a huge round of applause to Maxim Dounin for community support and technical excellence?

Maxim and team are answering the deepest of technical questions patiently, to the point.

Every time I read into those threads I am impressed by Maxim. By his dry communication style, his precision, and his patience. It's inspiring.

When you get his reply (which is likely to be the case), you typically get the problem you presented described in his words: with precise language/terms. Very likely he provides a solution. Or a precise quote of reference docs or spec describing why something doesn't work, conceptually. Or a patch (he often replies with "here's a patch that should work", showing a clean diff).

So: https://mailman.nginx.org/pipermail/nginx/ -- highly recommended if you want to learn more about HTTP and web servers in general.

By the way: for forcing DNS re-resolution (mentioned in this thread here) in the open source version by the way there is a weird but extremely powerful workaround (which really works, we have used it in DC/OS successfully over years), also see https://github.com/dcos/dcos/tree/master/packages/adminroute....

It was of course Maxim who described this little trick in the mailing list in 2011 :-) https://forum.nginx.org/read.php?2,215830,215832#msg-215832

It's still highly relevant in 2023 for controlled dynamic service discovery with nginx.

[sireat]

Is mailing list the recommended way to get help on nginx?

I recently made the mistake/challenge to use nginx as a SSL reverse proxy for a bunch of non SSL services running in docker containers .

To my dismay there is no decent documentation for what I thought would be a common usage case - namely docker for everything including nginx.

* SSL was easy enough - I have a wild card certificate and nginx does have good docs on setting it up

* Docker networking was a bit of pain - but I solved it by making a separate network.

* proxy_pass is where I got really bogged down - I got to rewrite location /api and serve it at the internal network + port.

        location /api/ {
        rewrite ^/api(.*)$ $1  break;
        # proxy_pass http://172.19.0.3; # also works
        proxy_pass http://172.19.0.1:9090;
        # most likely something else is needed for fix relative paths
        }

So now I have the problem that proxy works for mysite/api/index.html but not for any relative paths ie static/css/style.css is not loading (but docker exec -it mycontainer curl does work)

Maybe it is Google's fault but it seems near impossible to find a good AUTHORATIVE reference on setting up reverse proxy server with nginx.

[e12e]

Not entirely clear why you need to rewrite if you're also doing vhost based "routing" (wildcard certificate).

But as the saying went with apache, if you have a routing problem, you can fix it with mod_rewrite - now you have two problems!

You might want to (re)read:

https://nginx.org/en/docs/http/request_processing.html

and skim:

https://nginx.org/en/docs/http/load_balancing.html

And (re)read:

https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...

It seems dubious that you need any rewriting for your setup.

You might need a handful of server blocks (vhosts) with either proxy_pass or a few locations with proxy_pass?

[sireat]

Indeed I am wary of rewrite from apache days.

So using a subdomain should solve routing issues - api.myproject.myorg.org instead of myproject.myorg.org/api ?

Two issues - my wildcard cert is *.myorg.org so not 100% it would cover subdomains of subdomains.

Second issue - you'd need to set up DNS for subdomain of subdomain, would you not?

Sadly DNS setup would require opening an uncertain to complete support ticket in myorg...

[e12e]

> my wildcard cert is *.myorg.org so not 100% it would cover subdomains of subdomains.

it won't:

https://www.rfc-editor.org/rfc/rfc2818#section-3.1

> Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

[e12e]

Ah, I assumed you already had subdomains set up. Path based routing should be fine, but you probably still don't need rewriting - just "mount" the appropriate proxies in appropriate location blocks (read over the examples in the documentation carefully).

[k00shball]

There is also a community slack: https://www.nginx.com/blog/nginx-wants-you-join-us-on-the-ng...

[thebiss]

This sounds like an nginx-based k8s ingress-controller. See:

https://kubernetes.github.io/ingress-nginx/deploy/