On Mon, Mar 07, 2022 at 07:53:04PM +0000, Ben Mills wrote:

Hi there,

> Question-1
>
> Is there a directive to add to our nginx.conf server block that will force nginx to re-resolve its proxy_pass URL upon error? If not upon error, then perhaps at some configurable time interval?
>

As the parallel response says: for nginx, you can use resolver
(http://nginx.org/r/resolver) plus a hostname string that is not known at
startup (http://nginx.org/r/proxy_pass) -- note that using a variable in
proxy_pass, does have some limitations which do not apply in the config
that you showed.

"resolver" will re-resolve based on time -- either configured, or based
on the provided TTL value. I don't know that it can be triggered on
proxy_pass error.

(For information: nginx-plus does include some more options, outlined
in the "upstream" module documentation; they might be interesting if
the nginx application does not easily do what you want.)

> I have my eye on proxy_cache_use_stale, but not sure if this is suited to our use case.

I think "not entirely" -- that is for "this response has expired; shall I
send it anyway, instead of waiting for the upstream response". It will
send a response to the current request; but by itself it will never
cause the upstream address to be re-resolved.

> Question-2
>
> The devices using this setup are specialized and testing is not easy. Is there a command line option that will allow a user with SSH access to the EC2 instance where nginx is running to verify what nginx currently has in its cache for https://upstream? (i.e. rather than having to wait for a real device to error). The access.log does not display this information, only the error.log does.
>

I think this is looking for "what IP address(es) does nginx currently
associate with that upstream hostname".

As far as I know, no, there is not a command line option to learn that.

I think I would make a request to a known "test" url, and either watch
the error log, or watch the "tcpdump" output, to see what one IP address
attempts to be accessed. (And maybe make more requests to see if other
addresses are used as well; that does depend on the "hash" or other
load-balancing/persistence configuration.)

But: if you are not using "resolver", then you know that nginx is still
using what ever IP addresses it learned at startup. So "old logs" still
hold useful information.

Cheers,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org