You can find some good info on this here:
- https://serverfault.com/questions/108261/how-to-make-a-modification-take-affect-without-restarting-nginx serverfault.com - https://stackoverflow.com/questions/8982717/is-there-any-way-to-configure-nginx-or-other-quick-reverse-proxy-dynamically
Nginx has two methods of changing configuration: 1. HUP signal to the master process results in "reload". Nginx starts a bunch of new workers and lets the old workers to shutdown gracefully, i.e. they finish existing requests. There is no interruption of service. This method of configuration change is very lightweight and quick, but has few limitations: you cannot change cache zones or re-compile Perl scripts. 1. USR2 signal, then WINCH and then QUIT to the master process result in "executable upgrade" and this sequence lets completely re-read whole configuration and even upgrade the Nginx executable. It reloads disk caches as well (which maybe time consuming). This method results in no interruption of service too.
Nginx supports the following signals :
TERM, INT - Quick shutdown QUIT - Graceful shutdown HUP - Configuration reload: Start the new worker processes with a new configuration, Gracefully shutdown the old worker processes USR1 - Reopen the log files USR2 - Upgrade Executable on the fly WINCH - Gracefully shutdown the worker processes
HUP is what you are looking for, so:
sudo kill -HUP pid (nginx pid)
- http://nginx.org/en/docs/control.html
# With Caddy
If you can determine in advance where the proxy needs to go (i.e. from app state or some external check), you could generate your Caddyfile string in your application and feed it to the Caddy instance each time the requirements change (should be a graceful reload) - caddy.community 
- Caddy as a library - godoc
If you can’t (i.e. you need to determine the destination from some aspect of the request itself), it’s not going to be pretty, but you could start Caddy and then start up your own localhost listener, proxying everything to yourself, inspecting the request, and proxying it onwards. The second is a bit of a poor option because your app then needs to talk HTTP(S) anyway, so there’s little difference between this and having your own app without Caddy and just putting Caddy in front separately.
# With Nginx Plus
Update the list of available servers in your DNS and NGINX Plus automatically picks up the changes - nginx.com
To use DNS‑based reconfiguration, create multiple A records with the same hostname but different IP addresses, as in this example from Digital Ocean. The result is similar to what happens with Round Robin DNS, except that in this case NGINX Plus doesn’t just use the first address in the list from DNS as browser clients tend to do.
Instead it applies the configured load‑balancing algorithm to all the servers in the list, which can be Least Connections, Round Robin, or any of its other load balancing algorithms. NGINX Plus is effectively using the DNS server as a database for upstream servers.
# Using an HTTP‑Based API
NGINX Plus also provides an HTTP interface for adding, removing, and modifying backend servers dynamically and without having to reload the configuration. This is useful for autoscaling and when you want to take a server down temporarily for maintenance. It’s especially great for transient changes, as changes made using this interface are not preserved when you restart NGINX Plus or reload its configuration - nginx.com
# See also