Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upProxying two virtual hosts on the same machine routes to only one of them #1421
Comments
|
You could have a look at the generated nginx configuration to get an idea what went wrong or post ist here :)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment


I have a couple of Spring Cloud Config servers behind the proxy. Queries to either server are only dispatched to one of them - illustrated by a similar response (the dit server is configured to DIT git repo. organization, not the Development git organization).
Any ideas, or is this a defect?
$ curl -k https://serviceconfigdit/foo/application
{"name":"foo","profiles":["application"],"label":null,"version":"a1c4f51b753939c8ee10c392f3a0b236c97b659c","state":null,"propertySources":[{"name":"https://rc-github.dd.ent/Development/spring-config-server/foo.properties","source":{"foo":"from foo props","democonfigclient.message":"hello spring io dev"}}]}
$ curl -k https://serviceconfig**dev**/foo/application
{"name":"foo","profiles":["application"],"label":null,"version":"a1c4f51b753939c8ee10c392f3a0b236c97b659c","state":null,"propertySources":[{"name":"https://rc-github.dd.ent/Development/spring-config-server/foo.properties","source":{"foo":"from foo props","democonfigclient.message":"hello spring io dev"}}]}
Only the docker log for the dev server shows the query (confirming the dit request is routed to dev):
2020-04-15 09:21:29.792 INFO 10 --- [nio-8888-exec-4] o.s.c.c.s.e.NativeEnvironmentRepository : Adding property source: file:/tmp/config-repo-795975480269575774/foo.properties
2020-04-15 09:21:43.322 INFO 10 --- [nio-8888-exec-8] o.s.c.c.s.e.NativeEnvironmentRepository : Adding property source: file:/tmp/config-repo-795975480269575774/foo.properties
The nginx proxy is a derived image with the larger buffer set. All the images come up and run and are healthy. The certs are good and named conventionally to the DNS mapped names (serviceconfigdev.dd.ent and serviceconfigdit.dd.ent crt/key). The certs are locally generated SAN certs.
The hostname on which it's running is 10.6.253.128 and it's mapped in the DNS to it's fqdn and the names: serviceconfigdit.dd.ent and serviceconfigdev.dd.ent and serviceconfig - which is not used - I have checked they are set correctly.