update

mjang · mjang · commit faf6c58d6d7e · 2025-05-23T12:02:21.000-07:00
diff --git a/content/includes/agent/installation/install-agent-api.md b/content/includes/agent/installation/install-agent-api.md
@@ -1,74 +1,75 @@
-**Note**: To complete this step, make sure that `gpg` is installed on your system. You can install NGINX Agent using various command-line tools like `curl` or `wget`. If your NGINX Instance Manager host is not set up with valid TLS certificates, you can use the insecure flags provided by those tools. See the following examples:
+---
+docs: DOCS-1031
+files:
+  - content/nim/nginx-app-protect/setup-waf-config-management.md
+---
+
+{{<note>}}Make sure `gpg` is installed on your system before continuing. You can install NGINX Agent using command-line tools like `curl` or `wget`.{{</note>}}
+
+If your NGINX Instance Manager host doesn't use valid TLS certificates, you can use the insecure flags to bypass verification. Here are some example commands:
 
 {{<tabs name="install-agent-api">}}
 
 {{%tab name="curl"%}}
 
-- Secure:
+- **Secure:**
 
   ```bash
-  curl https://<NMS_FQDN>/install/nginx-agent | sudo sh
+  curl https://<NIM_FQDN>/install/nginx-agent | sudo sh
   ```
 
-- Insecure:
+- **Insecure:**
 
   ```bash
-  curl --insecure https://<NMS_FQDN>/install/nginx-agent | sudo sh
+  curl --insecure https://<NIM_FQDN>/install/nginx-agent | sudo sh
   ```
 
-  You can add your NGINX instance to an existing instance group or create one using `--instance-group` or `-g` flag when installing NGINX Agent.
-
-  The following example shows how to download and run the script with the optional `--instance-group` flag adding the NGINX instance to the instance group **my-instance-group**:
-
-  ```bash
-  curl https://<NMS_FQDN>/install/nginx-agent > install.sh; chmod u+x install.sh
-  sudo ./install.sh --instance-group my-instance-group
-  ```
+To add the instance to a specific instance group during installation, use the `--instance-group` (or `-g`) flag:
 
-  By default, the install script attempts to use a secure connection when downloading packages. If, however, the script cannot create a secure connection, it uses an insecure connection instead and logs the following warning message:
+```shell
+curl https://<NIM_FQDN>/install/nginx-agent -o install.sh
+chmod u+x install.sh
+sudo ./install.sh --instance-group <instance group>
+```
 
-  ``` text
-  Warning: An insecure connection will be used during this nginx-agent installation
-  ```
+By default, the install script uses a secure connection to download packages. If it can’t establish one, it falls back to an insecure connection and logs this message:
 
-  To require a secure connection, you can set the optional flag `skip-verify` to `false`.
+```text
+Warning: An insecure connection will be used during this nginx-agent installation
+```
 
-  The following example shows how to download and run the script with an enforced secure connection:
+To enforce a secure connection, set the `--skip-verify` flag to false:
 
-  ```bash
-  curl https://<NMS_FQDN>/install/nginx-agent > install.sh chmod u+x install.sh; chmod u+x install.sh
-  sudo sh ./install.sh --skip-verify false
-  ```
+```shell
+curl https://<NIM_FQDN>/install/nginx-agent -o install.sh
+chmod u+x install.sh
+sudo ./install.sh --skip-verify false
+```
 
 {{%/tab%}}
 
 {{%tab name="wget"%}}
 
+- **Secure:**
 
-- Secure:
-
-  ```bash
-  wget https://<NMS_FQDN>/install/nginx-agent -O - | sudo sh -s --skip-verify false
+  ```shell
+  wget https://<NIM_FQDN>/install/nginx-agent -O - | sudo sh -s --skip-verify false
   ```
 
-- Insecure:
+- **Insecure:**
 
-  ```bash
-  wget --no-check-certificate https://<NMS_FQDN>/install/nginx-agent -O - | sudo sh
+  ```shell
+  wget --no-check-certificate https://<NIM_FQDN>/install/nginx-agent -O - | sudo sh
   ```
 
-   When you install the NGINX Agent, you can use the  `--instance-group` or `-g` flag to add your NGINX instance to an existing instance group or to a new group that you specify.
-
-   The following example downloads and runs the NGINX Agent install script with the optional `--instance-group` flag, adding the NGINX instance to the instance group **my-instance-group**:
-
-   ```bash
-   wget https://gnms1.npi.f5net.com/install/nginx-agent -O install.sh ; chmod u+x install.sh
-   sudo ./install.sh --instance-group my-instance-group
-   ```
+To add your instance to a group during installation, use the `--instance-group` (or `-g`) flag:
 
+```shell
+wget https://<NIM_FQDN>/install/nginx-agent -O install.sh
+chmod u+x install.sh
+sudo ./install.sh --instance-group <instance group>
+```
 
 {{%/tab%}}
-{{</tabs>}}
 
-<!-- Do not remove. Keep this code at the bottom of the include -->
-<!-- DOCS-1031 -->
+{{</tabs>}}
diff --git a/content/includes/nap-waf/build-nginx-image-cmd.md b/content/includes/nap-waf/build-nginx-image-cmd.md
@@ -10,7 +10,7 @@ To build the image, execute the following command in the directory containing th
 
 
 ```shell
-sudo docker build --no-cache \
+sudo docker build --no-cache --platform linux/amd64 \
   --secret id=nginx-crt,src=nginx-repo.crt \
   --secret id=nginx-key,src=nginx-repo.key \
   -t nginx-app-protect-5 .
diff --git a/content/nap-dos/deployment-guide/learn-about-deployment.md b/content/nap-dos/deployment-guide/learn-about-deployment.md
@@ -1405,7 +1405,7 @@ You need root permissions to execute the following steps.
 6. Create a Docker image:
 
     ```shell
-    docker build --no-cache -t app-protect-dos .
+    docker build --no-cache --platform linux/amd64 -t app-protect-dos .
     ```
 
     The `--no-cache` option tells Docker to build the image from scratch and ensures the installation of the latest version of NGINX Plus and NGINX App Protect DoS. If the Dockerfile was previously used to build an image without the `--no-cache` option, the new image uses versions from the previously built image from the Docker cache.
@@ -1966,13 +1966,13 @@ Make sure to replace upstream and proxy pass directives in this example with rel
     For CentOS:
 
     ```shell
-    docker build --no-cache -t app-protect-dos .
+    docker build --no-cache --platform linux/amd64 -t app-protect-dos .
     ```
 
     For RHEL:
 
     ```shell
-    docker build --build-arg RHEL_ORGANIZATION=${RHEL_ORGANIZATION} --build-arg RHEL_ACTIVATION_KEY=${RHEL_ACTIVATION_KEY} --no-cache -t app-protect-dos .
+    docker build --platform linux/amd64 --build-arg RHEL_ORGANIZATION=${RHEL_ORGANIZATION} --build-arg RHEL_ACTIVATION_KEY=${RHEL_ACTIVATION_KEY} --no-cache -t app-protect-dos .
     ```
 
     The `--no-cache` option tells Docker to build the image from scratch and ensures the installation of the latest version of NGINX Plus and NGINX App Protect DoS. If the Dockerfile was previously used to build an image without the `--no-cache` option, the new image uses versions from the previously built image from the Docker cache.
diff --git a/content/nap-waf/v4/admin-guide/install.md b/content/nap-waf/v4/admin-guide/install.md
@@ -939,7 +939,7 @@ If a user other than **nginx** is to be used, note the following:
     - For Oracle Linux/Debian/Ubuntu/Alpine/Amazon Linux:
 
         ```shell
-        DOCKER_BUILDKIT=1 docker build --no-cache --secret id=nginx-crt,src=nginx-repo.crt --secret id=nginx-key,src=nginx-repo.key -t app-protect .
+        DOCKER_BUILDKIT=1 docker build --no-cache --platform linux/amd64 --secret id=nginx-crt,src=nginx-repo.crt --secret id=nginx-key,src=nginx-repo.key -t app-protect .
         ```
 
         The `DOCKER_BUILDKIT=1` enables `docker build` to recognize the `--secret` flag which allows the user to pass secret information to be used in the Dockerfile for building docker images in a safe way that will not end up stored in the final image. This is a recommended practice for the handling of the certificate and private key for NGINX repository access (`nginx-repo.crt` and `nginx-repo.key` files). More information [here](https://docs.docker.com/engine/reference/commandline/buildx_build/#secret).
@@ -1289,7 +1289,7 @@ You need root permissions to execute the following steps.
     - For Oracle Linux/Debian/Ubuntu/Alpine/Amazon Linux:
 
         ```shell
-        DOCKER_BUILDKIT=1 docker build --no-cache --secret id=nginx-crt,src=nginx-repo.crt --secret id=nginx-key,src=nginx-repo.key -t app-protect-converter .
+        DOCKER_BUILDKIT=1 docker build --no-cache --platform linux/amd64 --secret id=nginx-crt,src=nginx-repo.crt --secret id=nginx-key,src=nginx-repo.key -t app-protect-converter .
         ```
 
         The `DOCKER_BUILDKIT=1` enables `docker build` to recognize the `--secret` flag which allows the user to pass secret information to be used in the Dockerfile for building docker images in a safe way that will not end up stored in the final image. This is a recommended practice for the handling of the certificate and private key for NGINX repository access (`nginx-repo.crt` and `nginx-repo.key` files). More information [here](https://docs.docker.com/engine/reference/commandline/buildx_build/#secret).
diff --git a/content/nap-waf/v5/admin-guide/compiler.md b/content/nap-waf/v5/admin-guide/compiler.md
@@ -98,7 +98,7 @@ curl -s https://private-registry.nginx.com/v2/nap/waf-compiler/tags/list --key <
     Run the command below to build your image, where `waf-compiler-<version-tag>:custom` is an example of the image tag:
 
     ```shell
-    sudo docker build --no-cache \
+    sudo docker build --no-cache --platform linux/amd64 \
     --secret id=nginx-crt,src=nginx-repo.crt \
     --secret id=nginx-key,src=nginx-repo.key \
     -t waf-compiler-<version-tag>:custom .
diff --git a/content/ngf/overview/custom-policies.md b/content/ngf/overview/custom-policies.md
@@ -17,10 +17,11 @@ The following table summarizes NGINX Gateway Fabric custom policies:
 
 {{< bootstrap-table "table table-striped table-bordered" >}}
 
-| Policy                                                                                | Description                                             | Attachment Type | Supported Target Object(s)    | Supports Multiple Target Refs | Mergeable | API Version |
-|---------------------------------------------------------------------------------------|---------------------------------------------------------|-----------------|-------------------------------|-------------------------------|-----------|-------------|
-| [ClientSettingsPolicy]({{< ref "/ngf/how-to/traffic-management/client-settings.md" >}}) | Configure connection behavior between client and NGINX  | Inherited       | Gateway, HTTPRoute, GRPCRoute | No                            | Yes       | v1alpha1    |
-| [ObservabilityPolicy]({{< ref "/ngf/how-to/monitoring/tracing.md" >}})                  | Define settings related to tracing, metrics, or logging | Direct          | HTTPRoute, GRPCRoute          | Yes                           | No        | v1alpha1    |
+| Policy                                                                                      | Description                                             | Attachment Type | Supported Target Object(s)    | Supports Multiple Target Refs | Mergeable | API Version |
+|---------------------------------------------------------------------------------------------|---------------------------------------------------------|-----------------|-------------------------------|-------------------------------|-----------|-------------|
+| [ClientSettingsPolicy]({{< ref "/ngf/how-to/traffic-management/client-settings.md" >}})     | Configure connection behavior between client and NGINX  | Inherited       | Gateway, HTTPRoute, GRPCRoute | No                            | Yes       | v1alpha1    |
+| [ObservabilityPolicy]({{< ref "/ngf/how-to/monitoring/tracing.md" >}})                      | Define settings related to tracing, metrics, or logging | Direct          | HTTPRoute, GRPCRoute          | Yes                           | No        | v1alpha2    |
+| [UpstreamSettingsPolicy]({{< ref "/ngf/how-to/traffic-management/upstream-settings.md" >}}) | Configure connection behavior between NGINX and backend | Direct          | Service                       | Yes                           | Yes       | v1alpha1    |
 
 {{< /bootstrap-table >}}
 
diff --git a/content/ngf/overview/product-telemetry.md b/content/ngf/overview/product-telemetry.md
@@ -32,7 +32,8 @@ Telemetry data is collected once every 24 hours and sent to a service managed by
 - **Image Build Source:** whether the image was built by GitHub or locally (values are `gha`, `local`, or `unknown`). The source repository of the images is **not** collected.
 - **Deployment Flags:** a list of NGINX Gateway Fabric Deployment flags that are specified by a user. The actual values of non-boolean flags are **not** collected; we only record that they are either `true` or `false` for boolean flags and `default` or `user-defined` for the rest.
 - **Count of Resources:** the total count of resources related to NGINX Gateway Fabric. This includes `GatewayClasses`, `Gateways`, `HTTPRoutes`,`GRPCRoutes`, `TLSRoutes`, `Secrets`, `Services`, `BackendTLSPolicies`, `ClientSettingsPolicies`, `NginxProxies`, `ObservabilityPolicies`, `UpstreamSettingsPolicies`, `SnippetsFilters`, and `Endpoints`. The data within these resources is **not** collected.
-- **SnippetsFilters Info**a list of directive-context strings from applied SnippetFilters and a total count per strings. The actual value of any NGINX directive is **not** collected.
+- **SnippetsFilters Info:** a list of directive-context strings from applied SnippetFilters and a total count per strings. The actual value of any NGINX directive is **not** collected.
+
 This data is used to identify the following information:
 
 - The flavors of Kubernetes environments that are most popular among our users.
diff --git a/content/nginx/admin-guide/load-balancer/tcp-udp-load-balancer.md b/content/nginx/admin-guide/load-balancer/tcp-udp-load-balancer.md
@@ -9,26 +9,23 @@ type:
 - how-to
 ---
 
-<span id="intro"></span>
-## Introduction
+## Introduction {#intro}
 
-[Load balancing](https://www.nginx.com/solutions/load-balancing/) refers to efficiently distributing network traffic across multiple backend servers.
+[Load balancing](https://www.f5.com/glossary/load-balancer) refers to efficiently distributing network traffic across multiple backend servers.
 
 In F5 NGINX Plus [R5]({{< ref "nginx/releases.md#r5" >}}) and later, NGINX Plus can proxy and load balance Transmission Control Protocol) (TCP) traffic. TCP is the protocol for many popular applications and services, such as LDAP, MySQL, and RTMP.
 
 In NGINX Plus [R9]({{< ref "nginx/releases.md#r9" >}}) and later, NGINX Plus can proxy and load balance UDP traffic. UDP (User Datagram Protocol) is the protocol for many popular non-transactional applications, such as DNS, syslog, and RADIUS.
 
 To load balance HTTP traffic, refer to the [HTTP Load Balancing]({{< ref "http-load-balancer.md" >}}) article.
 
-<span id="prerequisites"></span>
 ## Prerequisites
 
 - Latest NGINX Plus (no extra build steps required) or latest [NGINX Open Source](https://nginx.org/en/download.html) built with the `--with-stream` configuration flag
 - An application, database, or service that communicates over TCP or UDP
 - Upstream servers, each running the same instance of the application, database, or service
 
-<span id="proxy_pass"></span>
-## Configuring Reverse Proxy
+## Configuring reverse proxy {#proxy_pass}
 
 First, you will need to configure _reverse proxy_ so that NGINX Plus or NGINX Open Source can forward TCP connections or UDP datagrams from clients to an upstream group or a proxied server.
 
@@ -118,8 +115,7 @@ Open the NGINX configuration file and perform the following steps:
    }
    ```
 
-<span id="upstream"></span>
-## Configuring TCP or UDP Load Balancing
+## Configuring TCP or UDP load balancing {#upstream}
 
 To configure load balancing:
 
@@ -250,17 +246,15 @@ stream {
 }
 ```
 
-<span id="health"></span>
-## Configuring Health Checks
+## Configuring health checks {#health}
 
 NGINX can continually test your TCP or UDP upstream servers, avoid the servers that have failed, and gracefully add the recovered servers into the load‑balanced group.
 
 See [TCP Health Checks]({{< ref "nginx/admin-guide/load-balancer/tcp-health-check.md" >}}) for instructions how to configure health checks for TCP.
 
 See [UDP Health Checks]({{< ref "nginx/admin-guide/load-balancer/udp-health-check.md" >}}) for instructions how to configure health checks for UDP.
 
-<span id="on-the-fly-configuration"></span>
-## On-the-Fly Configuration
+## On-the-fly configuration
 
 Upstream server groups can be easily reconfigured on-the-fly using NGINX Plus REST API. Using this interface, you can view all servers in an upstream group or a particular server, modify server parameters, and add or remove upstream servers.
 
@@ -355,8 +349,7 @@ To enable on-the-fly configuration:
    }
    ```
 
-<span id="on-the-fly-configuration-example"></span>
-### On-the-Fly Configuration Example
+### On-the-fly configuration example
 
 ```nginx
 stream {
@@ -403,23 +396,22 @@ For example, to add a new server to the server group, send a `POST` request:
 curl -X POST -d '{ \
    "server": "appserv3.example.com:12345", \
    "weight": 4 \
- }' -s 'http://127.0.0.1/api/6/stream/upstreams/appservers/servers'
+ }' -s 'http://127.0.0.1/api/9/stream/upstreams/appservers/servers'
 ```
 
 To remove a server from the server group, send a `DELETE` request:
 
 ```shell
-curl -X DELETE -s 'http://127.0.0.1/api/6/stream/upstreams/appservers/servers/0'
+curl -X DELETE -s 'http://127.0.0.1/api/9/stream/upstreams/appservers/servers/0'
 ```
 
 To modify a parameter for a specific server, send a  `PATCH` request:
 
 ```shell
-curl -X PATCH -d '{ "down": true }' -s 'http://127.0.0.1/api/6/http/upstreams/appservers/servers/0'
+curl -X PATCH -d '{ "down": true }' -s 'http://127.0.0.1/api/9/http/upstreams/appservers/servers/0'
 ```
 
-<span id="example"></span>
-## Example of TCP and UDP Load-Balancing Configuration
+## Example of TCP and UDP load-balancing configuration {#example}
 
 This is a configuration example of TCP and UDP load balancing with NGINX:
 
@@ -471,3 +463,13 @@ The three [`server`](https://nginx.org/en/docs/stream/ngx_stream_upstream_module
 - The second server listens on port 53 and proxies all UDP datagrams (the `udp` parameter to the `listen` directive) to an upstream group called **dns_servers**. If the `udp` parameter is not specified, the socket listens for TCP connections.
 
 - The third virtual server listens on port 12346 and proxies TCP connections to **backend4.example.com**, which can resolve to several IP addresses that are load balanced with the Round Robin method.
+
+## See also
+
+- [TCP Health Checks]({{< relref "tcp-health-check.md" >}})
+
+- [UDP Health Checks]({{< relref "udp-health-check.md" >}})
+
+- [Load Balancing DNS Traffic with NGINX and NGINX Plus](https://www.f5.com/company/blog/nginx/load-balancing-dns-traffic-nginx-plus)
+
+- [TCP/UDP Load Balancing with NGINX: Overview, Tips, and Tricks](https://blog.nginx.org/blog/tcp-load-balancing-udp-load-balancing-nginx-tips-tricks)
diff --git a/content/nginx/admin-guide/load-balancer/udp-health-check.md b/content/nginx/admin-guide/load-balancer/udp-health-check.md
diff --git a/content/nim/nginx-app-protect/manage-waf-security-policies.md b/content/nim/nginx-app-protect/manage-waf-security-policies.md
diff --git a/content/nim/nginx-app-protect/overview-nap-waf-config-management.md b/content/nim/nginx-app-protect/overview-nap-waf-config-management.md
