docs: clarify Docker port exposure for node operators

src/content/docs/network/nodes/full-node/deployments/using-docker.mdx

@@ -68,14 +68,22 @@ api:
 
 ```shellscript filename="Terminal"
 docker run --pull=always \
-  --rm -p 8080:8080 \
-  -p 9101:9101 -p 6180:6180 \
+  --rm -p 127.0.0.1:8080:8080 \
+  -p 127.0.0.1:9101:9101 -p 6182:6182 \
   -v $(pwd):/opt/aptos/etc -v $(pwd)/data:/opt/aptos/data \
   --workdir /opt/aptos/etc \
   --name=aptos-fullnode aptoslabs/validator:mainnet aptos-node \
   -f /opt/aptos/etc/fullnode.yaml
 ```
 
+<Aside type="caution">
+  **Published ports and host firewalls**<br />
+  Docker can install its own networking rules for published ports. If you do not want a service reachable from outside
+  the host, do not publish it publicly. In the example above, the REST API (`8080`) and inspection service (`9101`) are
+  bound to `127.0.0.1` so they stay host-local, while only the PFN public network port (`6182`) is exposed. After
+  starting the container, verify from a machine outside your host or VPC that the closed ports are not reachable.
+</Aside>
+
 <Aside type="caution">
   **Sudo access**<br />
   Note: you may need to prefix the docker command with `sudo` depending on your configuration.

src/content/docs/network/nodes/full-node/pfn-requirements.mdx

@@ -60,6 +60,14 @@ Assuming default ports are used, the following should be configured for PFNs:
   - `9102` – **Admin service**: Close this port to prevent unauthorized admin service interaction.
   - `80/8080` - **REST API**: Close this port to prevent unauthorized REST API access.
 
+<Aside type="tip">
+  **Containerized deployments**<br />
+  If you run your PFN in Docker or another container runtime, do not assume a host firewall rule by itself makes a
+  published port unreachable. Container networking can install its own forwarding rules. Avoid publishing the REST API
+  (`80` / `8080`), inspection (`9101`), and admin (`9102`) ports unless you explicitly need them, and verify from a
+  machine outside your host or VPC that those ports are not reachable.
+</Aside>
+
 <Aside type="caution">
   **Exposing services**<br />
   The inspection service port (`9101`), admin service port (`9102`) and the REST API port (`80` or `8080`)

src/content/docs/network/nodes/validator-node/deploy-nodes/using-docker.mdx

@@ -153,6 +153,17 @@ and VFN will be deployed on separate machines.
    - `digest_key.bin`: Validators only. DKG digest-key blob loaded by consensus.
    - `pp.bin`: Validators only. DKG public-parameters blob loaded by consensus.
 
+<Aside type="caution">
+  **Docker networking and published ports**<br />
+  Review the `ports:` sections in `docker-compose.yaml` and `docker-compose-fullnode.yaml` before starting the
+  containers. In Docker deployments, a host firewall rule alone may not block a port that is still published by
+  Compose. Publish only the ports each node role needs, keep REST/admin/inspection ports private unless explicitly
+  required, and verify from a machine outside your host or VPC that ports meant to stay closed are not reachable.
+  Keep the validator/VFN link port (`6181`) on a private network only; do not publish it on a public interface.
+  If a Compose file publishes `8080:8080` (or similar for `9101` / `9102`) and you do not want external access, either
+  remove that entry or bind it to a trusted interface, e.g., `127.0.0.1:8080:8080`.
+</Aside>
+
 7. To start the validator node, run the following command in your working directory:
 
    ```shellscript filename="Terminal"

src/content/docs/network/nodes/validator-node/node-requirements.mdx

@@ -158,6 +158,14 @@ Assuming default ports are used, the following should be configured for VFN node
   - `9102` – **Admin service**: Close this port to prevent unauthorized admin service interaction.
   - `80/8080` **REST API**: Close this port to prevent unauthorized REST API access.
 
+<Aside type="tip">
+  **Containerized deployments**<br />
+  If you run your validator or VFN in Docker or another container runtime, do not assume a host firewall rule by itself
+  makes a published port unreachable. Container networking can install its own forwarding rules. Avoid publishing ports
+  that should stay private unless you explicitly need them, and verify from a machine outside your host or VPC that the
+  ports you intend to keep closed are not reachable.
+</Aside>
+
 <Aside type="caution">
   **Exposing services**<br />
   The inspection service port (`9101`), admin service port (`9102`) and the REST API port (`80` or `8080`)

src/content/docs/zh/network/nodes/full-node/deployments/using-docker.mdx

@@ -60,14 +60,19 @@ api:
 
 ```shellscript filename="Terminal"
 docker run --pull=always \
-  --rm -p 8080:8080 \
-  -p 9101:9101 -p 6180:6180 \
+  --rm -p 127.0.0.1:8080:8080 \
+  -p 127.0.0.1:9101:9101 -p 6182:6182 \
   -v $(pwd):/opt/aptos/etc -v $(pwd)/data:/opt/aptos/data \
   --workdir /opt/aptos/etc \
   --name=aptos-fullnode aptoslabs/validator:mainnet aptos-node \
   -f /opt/aptos/etc/fullnode.yaml
 ```
 
+<Aside type="caution">
+  **已发布端口与主机防火墙**<br />
+  Docker 可能会为已发布端口安装自己的网络规则.如果您不希望某个服务能从主机外部访问,就不要将它公开发布.在上面的示例中,REST API(`8080`)和检查服务(`9101`)绑定到 `127.0.0.1`,因此它们只在主机本地可访问,而只有 PFN 公共网络端口(`6182`)对外暴露.启动容器后,请从主机或 VPC 外部的机器验证这些应关闭的端口确实无法访问.
+</Aside>
+
 <Aside type="caution">
   **需要 sudo 访问**<br />
   注意:根据您的配置,您可能需要在 docker 命令前加上 `sudo`.

src/content/docs/zh/network/nodes/full-node/pfn-requirements.mdx

@@ -46,6 +46,11 @@ import { Aside } from '@astrojs/starlight/components';
   - `9102` – **管理服务**:关闭此端口以防止未经授权的管理服务交互.
   - `80/8080` - **REST API**:关闭此端口以防止未经授权的 REST API 访问.
 
+<Aside type="tip">
+  **容器化部署**<br />
+  如果您在 Docker 或其他容器运行时中运行 PFN,不要假设仅靠主机防火墙规则就能让已发布的端口无法访问.容器网络可能会安装自己的转发规则.除非您明确需要,否则不要发布 REST API(`80` / `8080`),检查服务(`9101`)和管理服务(`9102`)端口,并且应从主机或 VPC 外部的机器验证这些端口确实无法访问.
+</Aside>
+
 <Aside type="caution">
   **暴露服务**<br />
   请注意,对于您的内部网络而言,如应用开发和调试,检查服务端口(9101),管理服务端口(9102)以及 REST API 端口(80 或 8080)可能会很有帮助.然而,检查服务端口和管理服务端口绝对不能公开到外网,因为很容易被滥用.同样地,如果您决定将 REST API 端点公开到外网,您应当部署额外的安全措施,比如认证机制或流量限制,以避免被滥用.

src/content/docs/zh/network/nodes/validator-node/deploy-nodes/using-docker.mdx

@@ -137,6 +137,11 @@ import { Aside } from '@astrojs/starlight/components';
    - `digest_key.bin`:仅验证器.由共识加载的 DKG digest-key blob.
    - `pp.bin`:仅验证器.由共识加载的 DKG 公共参数 blob.
 
+<Aside type="caution">
+  **Docker 网络与已发布端口**<br />
+  在启动容器之前,请检查 `docker-compose.yaml` 和 `docker-compose-fullnode.yaml` 中的 `ports:` 配置.在 Docker 部署中,如果端口仍由 Compose 发布,仅靠主机防火墙规则可能不足以阻止访问.只发布每种节点角色确实需要的端口,除非您明确需要,否则应保持 REST API / 管理 / 检查服务端口为私有,并从主机或 VPC 外部的机器验证本应关闭的端口确实无法访问.验证器与 VFN 之间的链路端口(`6181`)应只保留在私有网络上,不要发布到公共接口.如果 Compose 文件里发布了 `8080:8080`(或 `9101` / `9102` 的类似映射),而您又不希望外部访问,请删除该条目,或者将其绑定到受信任的接口,例如 `127.0.0.1:8080:8080`.
+</Aside>
+
 7. 要启动验证器节点,在您的工作目录中运行以下命令:
 
    ```shellscript filename="Terminal"

src/content/docs/zh/network/nodes/validator-node/node-requirements.mdx

@@ -120,12 +120,15 @@ Aptos 有三种网络类型:
   - `9102` – **管理服务**:关闭此端口以防止未经授权的管理服务交互.
   - `80/8080` **REST API**:关闭此端口以防止未经授权的 REST API 访问.
 
+<Aside type="tip">
+  **容器化部署**<br />
+  如果您在 Docker 或其他容器运行时中运行验证器或 VFN,不要假设仅靠主机防火墙规则就能让已发布的端口无法访问.容器网络可能会安装自己的转发规则.除非您明确需要,否则不要发布本应保持私有的端口,并且应从主机或 VPC 外部的机器验证您计划保持关闭的端口确实无法访问.
+</Aside>
+
 <Aside type="caution">
   **暴露服务**<br />
   检查服务端口(`9101`),管理服务端口(`9102`)和REST API端口(`80` 或 `8080`)
   可能对您的内部网络有用,例如,应用开发和调试.然而,检查服务端口和管理服务端口永远不应公开暴露,因为它们容易被滥用.同样,如果您选择公开暴露REST API端点,您应该部署额外的认证或速率限制机制以防止滥用.
-
-  检查服务端口(`9101`),管理服务端口(`9102`)以及 REST API 端口(`80` 或 `8080`)在您的内部网络中,可能会非常有用,比如说用于应用开发和调试时.但是,检查服务端口和管理服务端口绝对不能公开,因为这会很容易被滥用.同样,如果您决定将 REST API 端口公开,那么您应当部署额外的认证或限速措施,以避免滥用.
 </Aside>
 
 ## 软件要求