Fastcgi_pass, resolver, and validating functionality.

Maxim Dounin mdounin at mdounin.ru
Thu Dec 22 17:51:10 UTC 2016


Hello!

On Thu, Dec 22, 2016 at 11:55:00AM -0500, ahamilton9 wrote:

> Almost. It was static group in the respect that it was dynamically grabbed
> on load, but the resolver just wasn't triggering at all after that. 
> 
> We did not have an explicit group defined, "php" literally referred to the
> DNS name of the load balancer it was contacting. The rest of the domain was
> being taken care of by the local resolver (search domain).It looks like the
> code changed in nginx to completely rely on it's own DNS checking at some
> point rather than what the local system was reporting, which would explain
> why it suddenly stopped working after a version change when nothing else had
> been modified. 

System name resolution is only used when nginx parses 
configuration on startup / reconfiguration.  All name resolution 
during runtime uses DNS servers configured with the "resolver" 
directive.  And this is how it worked always, because system name resolution 
is blocking and can't be used by nginx during runtime.

> We changed the line from "php:9000" to the FQDN like
> "php.internal.ourdomain.com:9000", and the nginx resolver started
> triggering. To anyone who isn't using an FQDN and stumbles upon this, try
> that first.

Changing a name to a different one just makes sure that no other 
implicitly configured upstream group will interfere with the name 
used.

-- 
Maxim Dounin
http://nginx.org/


More information about the nginx mailing list