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 fran...@daoine.org _______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
