List of known issues in the latest release of NGINX for Azure
When creating a new deployment or exposing a new port for traffic, there might be a lag time of 5-10 seconds, during which the Azure Load Balancer does not recognize the new ports, thus preventing making new connections to the NGINX deployment.
Workaround: Wait 5-10 seconds to make requests, or make multiple requests to the instance with low connect timeout times after creating a new deployment or exposing a new port to the deployment (80/443) for the first 10 seconds after the deployment reaches the Completed state.
Files not listed with an include directive get an API 400 error response. NGINX configuration files are accepted if their filename matches an include directive using a glob pattern/mask (e.g.
Including njs files with the same name and different paths may result in unexpected behavior. We recommend to either not change the paths of uploaded njs files, or keep file names unique (such as a timestamp or version number).
As we do not yet support the use of
try_files and using NGINX as a web server, this issue is limited to the scope of njs and changing import paths via
Due to Azure Marketplace limitations, NGINX for Azure SKUs have a random suffix.
Workaround: When creating deployments via ARM templates, the correct SKU to use is
If an NGINX config uses an absolute path with the
js_import directive, the config will fail.
Workaround: If you need to use an absolute path, specify the absolute directory using
js_path, and use
js_import for the relative path.
NGINX for Azure resources appear with a random suffix, and clicking the link does not lead to the NGINX for Azure resource overview page. The charge details show “Unassigned” for all fields, but the charge amount is accurate.
Onboarding to WestEurope is not automatically available. If you want to use this region, please reach out to F5 submitting a request trough MyF5.
If a configuration update request uses a certificate that is in failed
provisioningState, the configuration update is rejected.
Workaround: Update the referenced certificate before updating the configuration. Make sure the certificate provisioning is successful and retry the configuration update.
NGINX for Azure should follow the same “Secure By Default” pattern as the ‘standard’ sku Azure Load Balancer. Currently NGINX For Azure will pass traffic through even if there is not a Network Security Group (NSG) associated with the subnet.