Configuration Changes That Restart Edge Node Gateway Processes
Most OpenResty Edge configurations (applications, page rules, upstreams, certificates, DNS records,
WAF rules, and so on) are hot-updated inside the gateway process and take effect as soon as they are
released. Only configurations that change the gateway node’s nginx.conf require a process update.
During a process update, the old processes try to finish the requests they are already serving, but their exit is bounded by the worker shutdown timeout and similar limits, so long-lived connections such as WebSocket, large downloads, and streaming responses may be dropped. Schedule such changes during off-peak hours.
Configuration Entries That Trigger a Process Update
| Console entry | Configuration involved | How it takes effect and its scope |
|---|---|---|
Global Config → General | Node runtime parameters under the categories listed on the right side of the page: Worker, IPv6, SSL, Proxy, Upstream, Client Request, File Buffer, Log, DNS, Gzip, Brotli, Zstandard, Cluster, OpenTelemetry, and Others | Must be released on the Global Config → Releases page after saving; affects the nodes of the partition selected at the top of the page. When Synchronize automatically to other partitions is enabled, releasing the default partition pushes the change to all partitions |
Gateway Clusters → Gateway Partitions → edit the partition’s port list | The partition’s listening port ranges and types, plus the HTTP/2 and PROXY protocol options of each port. The port list opened from an application’s partition field is the same configuration | Delivered immediately after saving, no separate release needed; affects nodes in all partitions |
Global Config → Global Metrics → OpenResty Edge Gateway Servers | The port and the allowed IP addresses of the Prometheus metrics service. The Admin metrics settings on the same page do not trigger it | Delivered immediately after saving; affects all gateway nodes |
Global Config → Global WAF → Syslog Server | The syslog output settings for WAF interception logs. The WAF rule sets on the same page do not trigger it | Delivered immediately after saving; affects all gateway nodes |
Global Config → Global Lua Modules | Modules with Run on startup enabled: adding, deleting, renaming, or changing the code of such a module, and turning the option on or off. Modules without this option do not trigger it. The option was introduced in version 26.6.1-1 | Triggered by the node’s periodic check after saving, usually within tens of seconds; affects the nodes of that partition |
Gateway Clusters → select a cluster → edit a node | Private IPv4, Server name, the Local IP addresses for listening and Local IP addresses for upstream requests of each protocol, Intel QAT Acceleration, Worker processes type, Worker processes number, Worker connections, Maximum number of open files, and Error log level | After saving and synchronization; affects that node only |
Gateway Clusters → edit a cluster | Partition and Is staging cluster — both change the set of configuration databases the nodes use | After saving and synchronization; affects all nodes in that cluster |
Gateway Clusters → select a cluster → edit a node → Is staging server | Switching a single node’s staging identity changes the set of configuration databases it uses | After saving and synchronization; affects that node only |
Saving the partition port list or the global metrics settings regenerates the runtime
configuration of every partition. If any partition still has unreleased General changes,
the save fails and asks you to release that partition first.
The following settings also live on the Global Config → General page, but they are saved through
separate APIs and never reach nginx.conf, so they do not trigger a process update:
Request ID, Strict health check, Enable OpenResty Edge error pages,
Synchronization gateway server status, Proxy Recursion, and Enable Cleanup Policy.
Summary
Whether a process update actually happens depends on whether the generated nginx.conf really
changes. If the content is identical, nothing is triggered — so changing a setting and then changing
it back before releasing produces no process update.
In non-container deployments, you can confirm that the update finished in the gateway node’s error
log (/usr/local/oredge-node/logs/error.log by default):
successfully binary upgraded OpenResty
Container deployments use a reload and do not print this line. Always match the log against the time of your change and the surrounding entries; do not draw a conclusion from a single old success message.