On Thu, Jul 23, 2020 at 02:30:42PM -0700, Kunal Punjabi wrote:
Hi there,
> Thanks for the response, and sorry for the delay here
No worries -- this list is not built for immediate responses.
> - I'm new to the
> mailing list and trying to figure out how the threads and responses are
> supposed to work (If I am not following the nginx digest's guidelines,
> please let me know)
Welcome to the list.
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of nginx digest..."
The only change I made in this response, was to edit the Subject: line
to match the original mail, instead of it being the generic "digest"
Subject line.
> *> Can you give some specific examples of "I make *this* request, and I
> want to get *this* response"? It looks like you have a nuxt.js http service
> listening on port 4001, and you want an nginx https service to listen on
> port 443 and reverse-proxy the 4001 service. But your
> suggested nginx config seems to try to do something different from that.*
> *So, in simple terms, this is what I have and this is what I want to
> happen:*
>
> - I have nuxt.js (frontend) running on a specific port, let's say 4001
> (this can be changed and does not matter).
Ok. I guess that your nuxt system must have some way to know
that "one.tinyadults.com" should get one set of content, while
"two.tinyadults.com" and "example.com" should both get a different set of
content. From what I understand, nginx does not need to care about that;
that is for nuxt-or-something-behind-it to handle.
> - So, a user (say user1) should be able to the app (tinyadults.com),
> specify their own subdomain URL, like user1.tinyadults.com,
> user2.tinyadults.com etc. I probably need a nginx config with "wildcard
> subdomains" to do this, which I also haven't figured out how to do.
If nginx should handle all incoming domain (server_name or Host:) requests
in the same way, then nginx does not need to care about the domains.
For just-http, your nginx config might be just
server {
listen 80 default;
location / {
proxy_pass http://localhost:4001;
}
}
with probably something like "proxy_set_header Host $host;" and maybe
some other proxy_* parts, depending on what your nuxt system does.
If you want to include https, then you will need to have a certificate
for every server_name that your clients might use to access nginx. That
would probably mean that you would have a server{} block like the above,
but with ssl enabled and a matching certificate, for each of those
server_name values.
> - They can also specify a custom domain (that they own), like domain1.com
> in the admin settings. What should happen is if you go to domain1.com,
> it would show the contents of that user's subdomain, user1.tinyadults.com
> in this example.
That sounds to me like it is not for your nginx to worry about.
If "domain1.com" is your nginx, then your nginx just proxy_pass'es to
nuxt as normal, and nuxt must know that domain1.com should get the same
content as user1.tinyadults.com.
If "domain1.com" is not your nginx, then domain1.com must know to
proxy_pass to user1.tinyadults.com (which *is* your nginx); and your
nginx just proxy_pass'es to nuxt as normal.
> It probably requires
> nginx and some DNS / CNAME changes, and we haven't been able to figure out
> how to get it to work.
All that DNS (including CNAME) does in this context, is get the client
to talk to your IP address when they want to talk to whatever name they
are looking for.
The DNS side has nothing to do with nginx.
> Our current nginx configs can be seen here
> https://gist.github.com/connecteev/f16b01e2aadbdcfbeb2e53f1b29cea04
Pretty much all nginx config starts with you deciding what you want
to have happen.
What is the full data flow that you care about?
When the user makes a request for "one.tinyadults.com" or
"two.tinyadults.com", DNS must make sure that the request gets to
your nginx.
After that: how do you want nginx to handle those two requests?
If you want a http request to be proxy_pass'ed to nuxt, configure your
nginx to do that (like is shown above). If you want a http request to
be redirected to a https equivalent of the same request, configure your
nginx to do that (like the "return 301" is your linked config).
If you want a https request to be handled by nginx, you must (for the
client's sake) first make sure that you present a certificate that the
client will accept; and then: what do you want nginx to do with the
request? If it is "proxy_pass to nuxt" -- do that. If it is something
else -- decide what that something else is, and then see how to configure
nginx to do it.
> So far, it's been like shooting darts blindfolded. If you could help figure
> this out, that would be so appreciated.
The hard part is you deciding what you want nginx to do with each request.
(Usually it will be "serve *this* file from the filesystem", or "redirect
to *this* http(s) url", or "proxy_pass to *this* http(s) url", or
"fastcgi_pass to the configured service, asking it to process *this*
filename". You just have to be very clear on how you want each request
to be handled.)
After that is decided, then you can worry about how to configure nginx
to do the thing that you want nginx to do.
That's where the documentation, the mailing list, and other resources
come in.
Good luck with it,
f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
