docs: clarify Global DR network requirements

docs/en/install/global_dr.mdx

@@ -68,7 +68,7 @@ The roles of **Primary Cluster** and **Standby Cluster** are relative: the clust
 2. Point the domain to the **Primary Cluster's** VIP and install the **Primary Cluster**;
 3. Temporarily switch DNS resolution to the standby VIP to install the Standby Cluster;
 4. Copy the ETCD encryption key of the **Primary Cluster** to the nodes that will later be the control plane nodes of Standby Cluster;
-5. Install and enable the etcd synchronization plugin;
+5. Install and enable **<Term name="product" /> etcd Synchronizer**;
 6. Verify sync status and perform regular checks;
 7. In case of failure, switch DNS to the standby cluster to complete disaster recovery.
 
@@ -77,7 +77,24 @@ The roles of **Primary Cluster** and **Standby Cluster** are relative: the clust
 * A unified domain which will be the `Platform Access Address`, and the TLS certificate plus private key for serving HTTPS on that domain;
 * A dedicated virtual IP address for each cluster — one for the **Primary Cluster** and another for the Standby Cluster;
 
-  * Preconfigure the load balancer to route TCP traffic on ports `80`, `443`, `6443`, `2379`, and `11443` to the control-plane nodes behind the corresponding VIP.
+### Network Requirements \{#network-requirements}
+
+The unified domain is a prerequisite for disaster recovery. During normal operation, the domain resolves only to the **Primary Cluster** VIP. The Standby Cluster uses the domain to access platform services on the Primary Cluster.
+
+Before installing either cluster, complete both of the following network preparations:
+
+* Configure each cluster's load balancer to forward the required TCP ports on its VIP to the control plane nodes behind that VIP. Configure port `80` only when users access the platform over HTTP.
+* Allow the required TCP ports in **both directions** between the Primary Cluster and Standby Cluster networks. Apply the rules to firewalls, security groups, router ACLs, and any other inter-site network controls.
+
+| TCP port | Service | Why it is required |
+|----------|---------|--------------------|
+| `443` | <Term name="productShort" /> platform HTTPS | The Standby Cluster uses the Platform Access Address to reach the active platform. **<Term name="product" /> etcd Synchronizer** uses this address, and logging and monitoring components send alert callbacks to it. |
+| `80` | <Term name="productShort" /> platform HTTP | Required only when users access the platform over HTTP. The connectivity requirement is otherwise the same as for port `443`. |
+| `6443` | Kubernetes API server | During installation or reinstallation of **<Term name="product" /> etcd Synchronizer**, the Standby Cluster connects to the active cluster API server to obtain the etcd CA material required for synchronization. |
+| `11443` | Built-in image registry | The Standby Cluster pulls platform and plugin images from the registry configured through the Platform Access Address. |
+| `2379` | etcd | **<Term name="product" /> etcd Synchronizer** on the Standby Cluster reads etcd data from the Primary Cluster and writes it to the local standby etcd. |
+
+The network policy must be bidirectional because the cluster roles are reversed after failover. Before failover, the effective service traffic is normally from Standby to Primary. After failover, the former Primary becomes the new Standby and must reach the new Primary on the same ports. This requirement does not make etcd replication bidirectional: **<Term name="product" /> etcd Synchronizer** runs only on the current Standby Cluster and writes synchronized data to its local etcd.
 
 ## Procedure
 
@@ -233,8 +250,8 @@ If the following components are installed, restart their services:
 
 ## Disaster Recovery Process
 
-<Directive type="danger" title="Verify primary/standby consistency before uninstalling the etcd synchronization plugin">
-This procedure uninstalls the etcd synchronization plugin. Before you uninstall it, confirm that the standby cluster data is consistent with the primary cluster. Uninstalling the plugin while the standby is missing data that the primary holds can cause owner references to resolve incorrectly, and workload-cluster node `Machine` objects — including immutable-OS clusters, where this destroys the backing virtual machine — may be deleted. If the consistency check reports missing or surplus keys, do not uninstall the plugin; resolve the inconsistency or contact technical support first.
+<Directive type="danger" title="Verify primary/standby consistency before uninstalling Alauda Container Platform etcd Synchronizer">
+This procedure uninstalls **<Term name="product" /> etcd Synchronizer**. Before you uninstall it, confirm that the standby cluster data is consistent with the primary cluster. Uninstalling the plugin while the standby is missing data that the primary holds can cause owner references to resolve incorrectly, and workload-cluster node `Machine` objects — including immutable-OS clusters, where this destroys the backing virtual machine — may be deleted. If the consistency check reports missing or surplus keys, do not uninstall the plugin; resolve the inconsistency or contact technical support first.
 </Directive>
 
 1. Restart Elasticsearch on the standby cluster in case it is necessary:
@@ -264,7 +281,7 @@ This procedure uninstalls the etcd synchronization plugin. Before you uninstall
     kubectl get machines.platform.tkestack.io
     ```
 
-3. Uninstall the etcd synchronization plugin;
+3. Uninstall **<Term name="product" /> etcd Synchronizer**;
 4. Remove port forwarding for `2379` from both VIPs;
 5. Switch the platform domain DNS to the standby VIP, which now becomes the Primary Cluster;
 6. Verify DNS resolution:

docs/en/install/prepare/prerequisites.mdx

@@ -227,6 +227,6 @@ This rule is designed to ensure that the `global` cluster can receive traffic fr
 
 <Directive type="tip" title="TIP">
 - It is recommended to configure health checks on the LoadBalancer to monitor the port status.
-- If you plan to implement a disaster recovery plan for the `global` cluster, you need to open port `2379` for all control plane nodes for ETCD data synchronization between the primary and disaster recovery clusters.
+- Global Cluster Disaster Recovery requires load balancer listeners on both cluster VIPs and bidirectional network access between the Primary and Standby Cluster networks. See [Network Requirements](../global_dr.mdx#network-requirements).
 - The platform only supports HTTPS by default. If HTTP support is required, you need to open the HTTP port for all control plane nodes.
 </Directive>