diff --git a/build/charts/antrea-windows/conf/antrea-agent.conf b/build/charts/antrea-windows/conf/antrea-agent.conf
index 5193ef5fd3c..be052638731 100644
--- a/build/charts/antrea-windows/conf/antrea-agent.conf
+++ b/build/charts/antrea-windows/conf/antrea-agent.conf
@@ -119,7 +119,7 @@ antreaProxy:
   # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will
   # not take effect on Service traffic.
   enable: true
-  # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
+  # Option proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
   # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled.
   # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
   # apiserver directly.
diff --git a/build/charts/antrea/conf/antrea-agent.conf b/build/charts/antrea/conf/antrea-agent.conf
index e140f3c0790..12d7a1595ed 100644
--- a/build/charts/antrea/conf/antrea-agent.conf
+++ b/build/charts/antrea/conf/antrea-agent.conf
@@ -342,7 +342,7 @@ antreaProxy:
 {{- with .Values.antreaProxy }}
   # To disable AntreaProxy, set this to false.
   enable: {{.enable}}
-  # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+  # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
   # regardless of where they come from. Therefore, running kube-proxy is no longer required.
   # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
   # apiserver directly.
@@ -365,7 +365,7 @@ antreaProxy:
   # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
   # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
   # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-  # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+  # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
   # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
   proxyLoadBalancerIPs: {{ .proxyLoadBalancerIPs }}
   # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
diff --git a/build/yamls/antrea-aks.yml b/build/yamls/antrea-aks.yml
index 1d9c4c57eff..70033d0ddcd 100644
--- a/build/yamls/antrea-aks.yml
+++ b/build/yamls/antrea-aks.yml
@@ -4038,7 +4038,7 @@ data:
     antreaProxy:
       # To disable AntreaProxy, set this to false.
       enable: true
-      # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+      # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
       # regardless of where they come from. Therefore, running kube-proxy is no longer required.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -4055,7 +4055,7 @@ data:
       # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
       # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
       # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
       # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
       proxyLoadBalancerIPs: true
       # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
@@ -5110,7 +5110,7 @@ spec:
         kubectl.kubernetes.io/default-container: antrea-agent
         # Automatically restart Pods with a RollingUpdate if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a
+        checksum/config: ed154450471cda0a19cc0ce08fc41f4fcca7da4326f6d1c28e2ae6d64855fffa
       labels:
         app: antrea
         component: antrea-agent
@@ -5348,7 +5348,7 @@ spec:
       annotations:
         # Automatically restart Pod if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a
+        checksum/config: ed154450471cda0a19cc0ce08fc41f4fcca7da4326f6d1c28e2ae6d64855fffa
       labels:
         app: antrea
         component: antrea-controller
diff --git a/build/yamls/antrea-eks.yml b/build/yamls/antrea-eks.yml
index 62e00bc5f1b..abd4fc4c304 100644
--- a/build/yamls/antrea-eks.yml
+++ b/build/yamls/antrea-eks.yml
@@ -4038,7 +4038,7 @@ data:
     antreaProxy:
       # To disable AntreaProxy, set this to false.
       enable: true
-      # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+      # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
       # regardless of where they come from. Therefore, running kube-proxy is no longer required.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -4055,7 +4055,7 @@ data:
       # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
       # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
       # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
       # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
       proxyLoadBalancerIPs: true
       # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
@@ -5110,7 +5110,7 @@ spec:
         kubectl.kubernetes.io/default-container: antrea-agent
         # Automatically restart Pods with a RollingUpdate if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a
+        checksum/config: ed154450471cda0a19cc0ce08fc41f4fcca7da4326f6d1c28e2ae6d64855fffa
       labels:
         app: antrea
         component: antrea-agent
@@ -5349,7 +5349,7 @@ spec:
       annotations:
         # Automatically restart Pod if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: f976029accf54258d01ad907fe19b50ac671eee014cd8aea968c6a0bc7e8f95a
+        checksum/config: ed154450471cda0a19cc0ce08fc41f4fcca7da4326f6d1c28e2ae6d64855fffa
       labels:
         app: antrea
         component: antrea-controller
diff --git a/build/yamls/antrea-gke.yml b/build/yamls/antrea-gke.yml
index 22665a948c9..bf73d2375d2 100644
--- a/build/yamls/antrea-gke.yml
+++ b/build/yamls/antrea-gke.yml
@@ -4038,7 +4038,7 @@ data:
     antreaProxy:
       # To disable AntreaProxy, set this to false.
       enable: true
-      # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+      # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
       # regardless of where they come from. Therefore, running kube-proxy is no longer required.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -4055,7 +4055,7 @@ data:
       # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
       # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
       # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
       # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
       proxyLoadBalancerIPs: true
       # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
@@ -5110,7 +5110,7 @@ spec:
         kubectl.kubernetes.io/default-container: antrea-agent
         # Automatically restart Pods with a RollingUpdate if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: 5299e6235e262daf606758cf900766470fcb8dd21a0d707a3ae284548bd8c2b2
+        checksum/config: 39a3b5c9eb43da28dd43f8d0995933589f3183bbfd94537cd237d4c710a3b119
       labels:
         app: antrea
         component: antrea-agent
@@ -5346,7 +5346,7 @@ spec:
       annotations:
         # Automatically restart Pod if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: 5299e6235e262daf606758cf900766470fcb8dd21a0d707a3ae284548bd8c2b2
+        checksum/config: 39a3b5c9eb43da28dd43f8d0995933589f3183bbfd94537cd237d4c710a3b119
       labels:
         app: antrea
         component: antrea-controller
diff --git a/build/yamls/antrea-ipsec.yml b/build/yamls/antrea-ipsec.yml
index 0c9afaa9857..930505984b1 100644
--- a/build/yamls/antrea-ipsec.yml
+++ b/build/yamls/antrea-ipsec.yml
@@ -4051,7 +4051,7 @@ data:
     antreaProxy:
       # To disable AntreaProxy, set this to false.
       enable: true
-      # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+      # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
       # regardless of where they come from. Therefore, running kube-proxy is no longer required.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -4068,7 +4068,7 @@ data:
       # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
       # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
       # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
       # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
       proxyLoadBalancerIPs: true
       # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
@@ -5123,7 +5123,7 @@ spec:
         kubectl.kubernetes.io/default-container: antrea-agent
         # Automatically restart Pods with a RollingUpdate if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: ba93df141f512a1f8483114b5994444c7231b298e7e9133483ddc1f4210ec395
+        checksum/config: 0ce19ca3c66fee6540241ed5c867173c892809f2cae06d32fed4d2e26b955ead
         checksum/ipsec-secret: d0eb9c52d0cd4311b6d252a951126bf9bea27ec05590bed8a394f0f792dcb2a4
       labels:
         app: antrea
@@ -5405,7 +5405,7 @@ spec:
       annotations:
         # Automatically restart Pod if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: ba93df141f512a1f8483114b5994444c7231b298e7e9133483ddc1f4210ec395
+        checksum/config: 0ce19ca3c66fee6540241ed5c867173c892809f2cae06d32fed4d2e26b955ead
       labels:
         app: antrea
         component: antrea-controller
diff --git a/build/yamls/antrea-windows-with-ovs.yml b/build/yamls/antrea-windows-with-ovs.yml
index a3b0987f0a9..7c5e23419f4 100644
--- a/build/yamls/antrea-windows-with-ovs.yml
+++ b/build/yamls/antrea-windows-with-ovs.yml
@@ -246,7 +246,7 @@ data:
       # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will
       # not take effect on Service traffic.
       enable: true
-      # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
+      # Option proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
       # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -306,7 +306,7 @@ spec:
     metadata:
       annotations:
         checksum/agent-windows: 86f999cb18501659a52d982f20b3df5cdf666ffd849f50ed183c366e75d01ac5
-        checksum/windows-config: 10ad2be0a04b1752abc224fed0124f7b1da36efc5e7323e193eb38e11b25e798
+        checksum/windows-config: 04323c2996bfd7e04467e3cb28b06444b3fcfad1fdbf1497e35f56450e21060b
         microsoft.com/hostprocess-inherit-user: "true"
       labels:
         app: antrea
diff --git a/build/yamls/antrea-windows.yml b/build/yamls/antrea-windows.yml
index 00d330405b7..c4990af41ac 100644
--- a/build/yamls/antrea-windows.yml
+++ b/build/yamls/antrea-windows.yml
@@ -174,7 +174,7 @@ data:
       # To disable AntreaProxy, set this to false. It should be enabled on Windows, otherwise NetworkPolicy will
       # not take effect on Service traffic.
       enable: true
-      # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
+      # Option proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
       # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -234,7 +234,7 @@ spec:
     metadata:
       annotations:
         checksum/agent-windows: 63f16e1fadb6b1354efda21c73702b4290400181136d4d47d4b1cd6a5f82d037
-        checksum/windows-config: 10ad2be0a04b1752abc224fed0124f7b1da36efc5e7323e193eb38e11b25e798
+        checksum/windows-config: 04323c2996bfd7e04467e3cb28b06444b3fcfad1fdbf1497e35f56450e21060b
         microsoft.com/hostprocess-inherit-user: "true"
       labels:
         app: antrea
diff --git a/build/yamls/antrea.yml b/build/yamls/antrea.yml
index b938d9f83bc..56f082e2cfb 100644
--- a/build/yamls/antrea.yml
+++ b/build/yamls/antrea.yml
@@ -4038,7 +4038,7 @@ data:
     antreaProxy:
       # To disable AntreaProxy, set this to false.
       enable: true
-      # ProxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
+      # Option proxyAll tells antrea-agent to proxy all Service traffic, including NodePort, LoadBalancer, and ClusterIP traffic,
       # regardless of where they come from. Therefore, running kube-proxy is no longer required.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
@@ -4055,7 +4055,7 @@ data:
       # External IPs of LoadBalancer Services. This is useful when the external LoadBalancer provides additional
       # capabilities (e.g. TLS termination) and it is desirable for Pod-to-ExternalIP traffic to be sent to the
       # external LoadBalancer instead of being load-balanced to an Endpoint directly by AntreaProxy.
-      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when ProxyAll is set to true and
+      # Note that setting ProxyLoadBalancerIPs to false usually only makes sense when proxyAll is set to true and
       # kube-proxy is removed from the cluster, otherwise kube-proxy will still load-balance this traffic.
       proxyLoadBalancerIPs: true
       # The value of the "service.kubernetes.io/service-proxy-name" label for AntreaProxy to match. If it is set,
@@ -5110,7 +5110,7 @@ spec:
         kubectl.kubernetes.io/default-container: antrea-agent
         # Automatically restart Pods with a RollingUpdate if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: aca23e21519e0fc112647f23d3ce6f92a3dea0bc7ebf1c6d7a7eed2dbe80f0a3
+        checksum/config: 2fea99cb84bc61aa21cd6d259a1e15f245634fe14f9b567c54d8bfe9bbb3e0f7
       labels:
         app: antrea
         component: antrea-agent
@@ -5346,7 +5346,7 @@ spec:
       annotations:
         # Automatically restart Pod if the ConfigMap changes
         # See https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments
-        checksum/config: aca23e21519e0fc112647f23d3ce6f92a3dea0bc7ebf1c6d7a7eed2dbe80f0a3
+        checksum/config: 2fea99cb84bc61aa21cd6d259a1e15f245634fe14f9b567c54d8bfe9bbb3e0f7
       labels:
         app: antrea
         component: antrea-controller
diff --git a/docs/antrea-ipam.md b/docs/antrea-ipam.md
index 3e4a412443a..41baa073e5a 100644
--- a/docs/antrea-ipam.md
+++ b/docs/antrea-ipam.md
@@ -278,8 +278,8 @@ where the underlay router will route the traffic to the destination VLAN.
 ### Requirements for this Feature
 
 As of now, this feature is supported on Linux Nodes, with IPv4, `system` OVS datapath
-type, `noEncap`, `noSNAT` traffic mode, and `AntreaProxy` feature enabled. Configuration
-with `ProxyAll` feature enabled is not verified.
+type, `noEncap`, `noSNAT` traffic mode, and Antrea Proxy enabled. Configuration
+with `proxyAll` enabled is not verified.
 
 The IPs in the `IPPools` without VLAN must be in the same underlay subnet as the Node
 IP, because inter-Node traffic of AntreaIPAM Pods is forwarded by the Node network.
diff --git a/docs/antrea-network-policy.md b/docs/antrea-network-policy.md
index 96ed35c1fcc..db4e27e226a 100644
--- a/docs/antrea-network-policy.md
+++ b/docs/antrea-network-policy.md
@@ -1490,7 +1490,7 @@ Kubernetes](https://kubernetes.io/docs/concepts/services-networking/dns-pod-serv
 Services. The reason is that Antrea will use the information included in A or
 AAAA DNS records to implement FQDN based policies. In the case of "normal" (not
 headless) Services, the DNS name resolves to the ClusterIP for the Service, but
-policy rules are enforced after AntreaProxy Service Load-Balancing and at that
+policy rules are enforced after Antrea Proxy Service Load-Balancing and at that
 stage the destination IP address has already been rewritten to the address of an
 endpoint backing the Service. For headless Services, a ClusterIP is not
 allocated and, assuming the Service has a selector, the DNS server returns A /
@@ -1571,8 +1571,8 @@ A combination of Service name and Service Namespace can be used in `toServices`
 by this field. A sample policy can be found [here](#acnp-for-toservices-rule).
 
 Since `toServices` represents a combination of IP+port, it cannot be used with `to` or `ports` within the same egress rule.
-Also, since the matching process relies on the groupID assigned to Service by AntreaProxy, this field can only be used when
-AntreaProxy is enabled.
+Also, since the matching process relies on the groupID assigned to Service by Antrea Proxy, this field can only be used when
+Antrea Proxy is enabled.
 
 This clusterIP-based match has one caveat: direct access to the Endpoints of this Service is not affected by
 `toServices` rules. To restrict access towards backend Endpoints of a Service, define a `ClusterGroup` with `ServiceReference`
@@ -1952,11 +1952,11 @@ Similar RBAC is applied to the ClusterGroup resource.
   won't be blocked by new rules.
 - For hairpin Service traffic, when a Pod initiates traffic towards the Service it
   provides, and the same Pod is selected as the Endpoint, NetworkPolicies will
-  consistently permit this traffic during ingress enforcement if AntreaProxy is enabled,
+  consistently permit this traffic during ingress enforcement if Antrea Proxy is enabled,
   irrespective of the ingress rules defined by the user. In the presence of ingress rules
   preventing access to the Service from Pods providing the Service, accessing the Service
   from one of these Pods will succeed if traffic is hairpinned back to the source Pod, and
-  will fail if a different Endpoint is selected by AntreaProxy. However, when AntreaProxy
+  will fail if a different Endpoint is selected by Antrea Proxy. However, when Antrea Proxy
   is disabled, NetworkPolicies may not function as expected for hairpin Service traffic.
   This is due to kube-proxy performing SNAT, which conceals the original source IP from
   Antrea. Consequently, NetworkPolicies are unable to differentiate between hairpin
diff --git a/docs/antrea-proxy.md b/docs/antrea-proxy.md
index 5164367db31..ccdf1ba31c2 100644
--- a/docs/antrea-proxy.md
+++ b/docs/antrea-proxy.md
@@ -1,10 +1,10 @@
-# AntreaProxy
+# Antrea Proxy
 
 ## Table of Contents
 
 <!-- toc -->
 - [Introduction](#introduction)
-- [AntreaProxy with proxyAll](#antreaproxy-with-proxyall)
+- [Antrea Proxy with proxyAll](#antrea-proxy-with-proxyall)
   - [Removing kube-proxy](#removing-kube-proxy)
     - [Windows Nodes](#windows-nodes)
   - [Configuring load balancer mode for external traffic](#configuring-load-balancer-mode-for-external-traffic)
@@ -16,26 +16,26 @@
 
 ## Introduction
 
-AntreaProxy was first introduced in Antrea v0.8 and has been enabled by default
-on all platforms since v0.11. AntreaProxy enables some or all of the cluster's
+Antrea Proxy was first introduced in Antrea v0.8 and has been enabled by default
+on all platforms since v0.11. Antrea Proxy enables some or all of the cluster's
 Service traffic to be load-balanced as part of the OVS pipeline, instead of
 depending on kube-proxy. We typically observe latency improvements for Service
-traffic when AntreaProxy is used.
+traffic when Antrea Proxy is used.
 
-While AntreaProxy can be disabled on Linux Nodes by setting the `AntreaProxy`
+While Antrea Proxy can be disabled on Linux Nodes by setting the `AntreaProxy`
 Feature Gate to `false`, it should remain enabled on all Windows Nodes, as it is
 needed for correct NetworkPolicy implementation for Pod-to-Service traffic.
 
-By default, AntreaProxy will only handle Service traffic originating from Pods
+By default, Antrea Proxy will only handle Service traffic originating from Pods
 in the cluster, with no support for NodePort. However, starting with Antrea
-v1.4, a new operating mode was introduced in which AntreaProxy can handle all
+v1.4, a new operating mode was introduced in which Antrea Proxy can handle all
 Service traffic, including NodePort. See the following
-[section](#antreaproxy-with-proxyall) for more information.
+[section](#antrea-proxy-with-proxyall) for more information.
 
-## AntreaProxy with proxyAll
+## Antrea Proxy with proxyAll
 
 The `proxyAll` configuration parameter can be enabled in the Antrea
-configuration if you want AntreaProxy to handle all Service traffic, with the
+configuration if you want Antrea Proxy to handle all Service traffic, with the
 possibility to remove kube-proxy altogether and have one less DaemonSet running
 in the cluster. This is particularly interesting on Windows Nodes, since until
 the introduction of `proxyAll`, Antrea relied on userspace kube-proxy, which is
@@ -43,19 +43,19 @@ no longer actively maintained by the K8s community and is slower than other
 kube-proxy backends.
 
 Note that on Linux, before Antrea v2.1, when `proxyAll` is enabled, kube-proxy
-will usually take priority over AntreaProxy and will keep handling all kinds of
+will usually take priority over Antrea Proxy and will keep handling all kinds of
 Service traffic (unless the source is a Pod, which is pretty unusual as Pods
 typically access Services by ClusterIP). This is because kube-proxy rules typically
-come before the rules installed by AntreaProxy to redirect traffic to OVS. When
-kube-proxy is not deployed or is removed from the cluster, AntreaProxy will then
+come before the rules installed by Antrea Proxy to redirect traffic to OVS. When
+kube-proxy is not deployed or is removed from the cluster, Antrea Proxy will then
 handle all Service traffic.
 
-Starting with Antrea v2.1, when `proxyAll` is enabled, AntreaProxy will handle
+Starting with Antrea v2.1, when `proxyAll` is enabled, Antrea Proxy will handle
 Service traffic destined to NodePort, LoadBalancerIP and ExternalIP, even if
 kube-proxy is present. This benefits users who want to take advantage of
-AntreaProxy's advanced features, such as Direct Server Return (DSR) mode, but
+Antrea Proxy's advanced features, such as Direct Server Return (DSR) mode, but
 lack control over kube-proxy's installation. This is accomplished by
-prioritizing the rules installed by AntreaProxy over those installed by
+prioritizing the rules installed by Antrea Proxy over those installed by
 kube-proxy, thus it works only with kube-proxy iptables mode. Support for other
 kube-proxy modes may be added in the future.
 
@@ -141,7 +141,7 @@ kube-proxy:
 
 Starting with Antrea v1.13, the `defaultLoadBalancerMode` configuration
 parameter and the `service.antrea.io/load-balancer-mode` Service annotation
-can be used to specify how you want AntreaProxy to handle external traffic
+can be used to specify how you want Antrea Proxy to handle external traffic
 destined to LoadBalancerIPs and ExternalIPs of Services. Specifically, the mode
 determines how external traffic is processed when it's load balanced across
 Nodes. Currently, it has two options: `nat` (default) and `dsr`.
@@ -209,8 +209,8 @@ configured to bind to that address and can therefore intercept queries. In case
 of a cache miss, queries can be sent to the cluster CoreDNS Pods thanks to a
 "shadow" Service which will expose CoreDNS Pods via a new ClusterIP.
 
-When AntreaProxy is enabled (default), Pod DNS queries to the kube-dns ClusterIP
-will be load-balanced directly by AntreaProxy to a CoreDNS Pod endpoint. This
+When Antrea Proxy is enabled (default), Pod DNS queries to the kube-dns ClusterIP
+will be load-balanced directly by Antrea Proxy to a CoreDNS Pod endpoint. This
 means that NodeLocal DNSCache is completely bypassed, which is probably not
 acceptable for users who want to leverage this feature to improve DNS
 performance in their clusters. While these users can update the Pod
@@ -219,8 +219,8 @@ interface, this is not always ideal in the context of CaaS, as it can require
 everyone running Pods in the cluster to be aware of the situation.
 
 This is the reason why we initially introduced the `skipServices` configuration
-option for AntreaProxy in Antrea v1.4. By adding the kube-dns Service (which
-exposes CoreDNS) to the list, you can ensure that AntreaProxy will "ignore" Pod
+option for Antrea Proxy in Antrea v1.4. By adding the kube-dns Service (which
+exposes CoreDNS) to the list, you can ensure that Antrea Proxy will "ignore" Pod
 DNS queries, and that they will be forwarded to NodeLocal DNSCache. You can edit
 the `antrea-config` ConfigMap as follows:
 
@@ -241,11 +241,11 @@ data:
 In some cases, the external LoadBalancer for a cluster provides additional
 capabilities (e.g., TLS termination) and it is desirable for Pods to access
 in-cluster Services through the external LoadBalancer. By default, this is not
-the case as both kube-proxy and AntreaProxy will install rules to load-balance
+the case as both kube-proxy and Antrea Proxy will install rules to load-balance
 this traffic directly at the source Node (even when the destination IP is set to
 the external `loadBalancerIP`). To circumvent this behavior, we introduced the
-`proxyLoadBalancerIPs` configuration option for AntreaProxy in Antrea v1.5. This
-option defaults to `true`, but when setting it to `false`, AntreaProxy will no
+`proxyLoadBalancerIPs` configuration option for Antrea Proxy in Antrea v1.5. This
+option defaults to `true`, but when setting it to `false`, Antrea Proxy will no
 longer load-balance traffic destined to external `loadBalancerIP`s, hence
 ensuring that this traffic can go to the external LoadBalancer. You can set it
 to `false` by editing the `antrea-config` ConfigMap as follows:
@@ -262,7 +262,7 @@ data:
       proxyLoadBalancerIPs: false
 ```
 
-With the above configuration, AntreaProxy will ignore all external `loadBalancerIP`s.
+With the above configuration, Antrea Proxy will ignore all external `loadBalancerIP`s.
 Starting with K8s v1.29, feature [LoadBalancerIPMode](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-ip-mode)
 was introduced, providing users with a more fine-grained mechanism to control how
 every external `loadBalancerIP` behaves in a LoadBalancer Service.
@@ -274,12 +274,12 @@ every external `loadBalancerIP` behaves in a LoadBalancer Service.
   destined for the corresponding external `loadBalancerIP` should be sent to the
   external LoadBalancer.
 
-Starting with Antrea v2.0, AntreaProxy will respect `LoadBalancerIPMode` in LoadBalancer
+Starting with Antrea v2.0, Antrea Proxy will respect `LoadBalancerIPMode` in LoadBalancer
 Services when the configuration option `proxyLoadBalancerIPs` is set to `true`
-(default). In this case, AntreaProxy will serve only the external `loadBalancerIP`s
+(default). In this case, Antrea Proxy will serve only the external `loadBalancerIP`s
 configured with `LoadBalancerIPModeVIP`, and those configured with
-`LoadBalancerIPModeProxy` will bypass AntreaProxy. If the configuration option
-`proxyLoadBalancerIPs` is set to `false`, AntreaProxy will ignore the external
+`LoadBalancerIPModeProxy` will bypass Antrea Proxy. If the configuration option
+`proxyLoadBalancerIPs` is set to `false`, Antrea Proxy will ignore the external
 `loadBalancerIP`s even if configured with `LoadBalancerIPModeVIP`.
 
 There are two important prerequisites for this feature:
diff --git a/docs/design/architecture.md b/docs/design/architecture.md
index 140a46e9087..1567195288a 100644
--- a/docs/design/architecture.md
+++ b/docs/design/architecture.md
@@ -205,7 +205,7 @@ so their source IP will be rewritten to the Node's IP before going out.
 ### ClusterIP Service
 
 Antrea supports two ways to implement Services of type ClusterIP - leveraging
-`kube-proxy`, or AntreaProxy that implements load balancing for ClusterIP
+`kube-proxy`, or Antrea Proxy that implements load balancing for ClusterIP
 Service traffic with OVS.
 
 When leveraging `kube-proxy`, Antrea Agent adds OVS flows to forward the packets
@@ -222,12 +222,12 @@ the tunnel.
 See the [Kubernetes Service Proxies documentation](https://kubernetes.io/docs/reference/networking/virtual-ips)
 for more details.
 
-When AntreaProxy is enabled, Antrea Agent will add OVS flows that implement
+When Antrea Proxy is enabled, Antrea Agent will add OVS flows that implement
 load balancing and DNAT for the ClusterIP Service traffic. In this way, Service
 traffic load balancing is done inside OVS together with the rest of the
 forwarding, and it can achieve better performance than using `kube-proxy`, as
 there is no extra overhead of forwarding Service traffic to the host's network
-stack and iptables processing. The AntreaProxy implementation in Antrea Agent
+stack and iptables processing. The Antrea Proxy implementation in Antrea Agent
 leverages some `kube-proxy` packages to watch and process Service Endpoints.
 
 ### NetworkPolicy
diff --git a/docs/design/ovs-pipeline.md b/docs/design/ovs-pipeline.md
index 0dcf9ff7e07..5f3aecd2f07 100644
--- a/docs/design/ovs-pipeline.md
+++ b/docs/design/ovs-pipeline.md
@@ -257,7 +257,7 @@ Like K8s NetworkPolicy, several tables of the pipeline are dedicated to [Kuberne
 Service](https://kubernetes.io/docs/concepts/services-networking/service/) implementation (tables [NodePortMark],
 [SessionAffinity], [ServiceLB], and [EndpointDNAT]).
 
-By enabling `proxyAll`, ClusterIP, NodePort, LoadBalancer, and ExternalIP are all handled by AntreaProxy. Otherwise,
+By enabling `proxyAll`, ClusterIP, NodePort, LoadBalancer, and ExternalIP are all handled by Antrea Proxy. Otherwise,
 only in-cluster ClusterIP is handled. In this document, we use the sample K8s Services below. These Services select Pods
 with the label `app: web` as Endpoints.
 
@@ -788,12 +788,13 @@ Flow 1 is for case 1, matching packets received on the local Antrea gateway port
 addresses. There are some cases where the source IP of the packets through the local Antrea gateway port is not the local
 Antrea gateway IP address:
 
-- When Antrea is deployed with kube-proxy, and `AntreaProxy` is not enabled, packets from local Pods destined for Services
-  will first go through the gateway port, get load-balanced by the kube-proxy data path (undergoes DNAT) then re-enter
-  the OVS pipeline through the gateway port (through an "onlink" route, installed by Antrea, directing the DNAT'd packets
-  to the gateway port), resulting in the source IP being that of a local Pod.
-- When Antrea is deployed without kube-proxy, and both `AntreaProxy` and `proxyAll` are enabled, packets from the external
-  network destined for Services will be routed to OVS through the gateway port without masquerading source IP.
+- When Antrea is deployed with kube-proxy, and the feature `AntreaProxy` is not enabled, packets from local Pods destined
+  for Services will first go through the gateway port, get load-balanced by the kube-proxy data path (undergoes DNAT)
+  then re-enter the OVS pipeline through the gateway port (through an "onlink" route, installed by Antrea, directing the
+  DNAT'd packets to the gateway port), resulting in the source IP being that of a local Pod.
+- When Antrea is deployed without kube-proxy, and both the feature `AntreaProxy` and option `proxyAll` are enabled,
+  packets from the external network destined for Services will be routed to OVS through the gateway port without
+  masquerading source IP.
 - When Antrea is deployed with kube-proxy, packets from the external network destined for Services whose
   `externalTrafficPolicy` is set to `Local` will get load-balanced by the kube-proxy data path (undergoes DNAT with a
   local Endpoint selected by the kube-proxy) and then enter the OVS pipeline through the gateway (through a "onlink"
@@ -1303,7 +1304,7 @@ through the local Antrea gateway. In other words, these are connections for whic
 (SYN packet for TCP) was received through the local Antrea gateway. It rewrites the destination MAC address to
 that of the local Antrea gateway, loads `ToGatewayRegMark`, and forwards them to table [L3DecTTL]. This ensures that
 reply packets can be forwarded back to the local Antrea gateway in subsequent tables. This flow is required to handle
-the following cases when AntreaProxy is not enabled:
+the following cases when Antrea Proxy is not enabled:
 
 - Reply traffic for connections from a local Pod to a ClusterIP Service, which are handled by kube-proxy and go through
   DNAT. In this case, the destination IP address of the reply traffic is the Pod which initiated the connection to the
diff --git a/docs/design/windows-design.md b/docs/design/windows-design.md
index 0d80658c8c4..592d0f2f2d2 100644
--- a/docs/design/windows-design.md
+++ b/docs/design/windows-design.md
@@ -210,7 +210,7 @@ Kube-proxy userspace mode is configured to provide NodePort Service function. A
 "HNS Internal NIC" is provided to kube-proxy to configure Service addresses. The OpenFlow entries for the
 NodePort Service traffic on Windows are the same as those on Linux.
 
-AntreaProxy implements the ClusterIP Service function. Antrea Agent installs routes to send ClusterIP Service
+Antrea Proxy implements the ClusterIP Service function. Antrea Agent installs routes to send ClusterIP Service
 traffic from host network to the OVS bridge. For each Service, it adds a route that routes the traffic via a
 virtual IP (169.254.0.253), and it also adds a route to indicate that the virtual IP is reachable via
 antrea-gw0. The reason to add a virtual IP, rather than routing the traffic directly to antrea-gw0, is that
diff --git a/docs/feature-gates.md b/docs/feature-gates.md
index 287d9dacc58..8efb4388ed9 100644
--- a/docs/feature-gates.md
+++ b/docs/feature-gates.md
@@ -64,18 +64,15 @@ edit the Agent configuration in the
 
 ### AntreaProxy
 
-`AntreaProxy` implements Service load-balancing for ClusterIP Services as part of the OVS pipeline, as opposed to
-relying on kube-proxy. This only applies to traffic originating from Pods, and destined to ClusterIP Services. In
-particular, it does not apply to NodePort Services. Please note that due to some restrictions on the implementation of
-Services in Antrea, the maximum number of Endpoints that Antrea can support at the moment is 800. If the number of
-Endpoints for a given Service exceeds 800, extra Endpoints will be dropped.
+`AntreaProxy` enables Antrea Proxy which implements Service load-balancing for ClusterIP Services as part of the OVS
+pipeline, as opposed to relying on kube-proxy. By default, this only applies to traffic originating from Pods, and
+destined to ClusterIP Services. However, it can be configured to support all types of Services, replacing kube-proxy
+entirely. Please refer to this [document](antrea-proxy.md) for extra information on Antrea Proxy and how it can be configured.
 
 Note that this feature must be enabled for Windows. The Antrea Windows YAML manifest provided as part of releases
 enables this feature by default. If you edit the manifest, make sure you do not disable it, as it is needed for correct
 NetworkPolicy implementation for Pod-to-Service traffic.
 
-Please refer to this [document](antrea-proxy.md) for extra information on AntreaProxy and how it can be configured.
-
 #### Requirements for this Feature
 
 When using the OVS built-in kernel module (which is the most common case), your kernel version must be >= 4.6 (as
@@ -83,9 +80,9 @@ opposed to >= 4.4 without this feature).
 
 ### EndpointSlice
 
-`EndpointSlice` enables Service EndpointSlice support in AntreaProxy. The EndpointSlice API was introduced in Kubernetes
+`EndpointSlice` enables Service EndpointSlice support in Antrea Proxy. The EndpointSlice API was introduced in Kubernetes
 1.16 (alpha) and it is enabled by default in Kubernetes 1.17 (beta), promoted to GA in Kubernetes 1.21. The EndpointSlice
-feature will take no effect if AntreaProxy is not enabled. Refer to this [link](https://kubernetes.io/docs/tasks/administer-cluster/enabling-endpointslices/)
+feature will take no effect if Antrea Proxy is not enabled. Refer to this [link](https://kubernetes.io/docs/tasks/administer-cluster/enabling-endpointslices/)
 for more information about EndpointSlice. If this feature is enabled but the EndpointSlice v1 API is not available
 (Kubernetes version is lower than 1.21), Antrea Agent will log a message and fallback to the Endpoints API.
 
@@ -96,7 +93,7 @@ for more information about EndpointSlice. If this feature is enabled but the End
 
 ### TopologyAwareHints
 
-`TopologyAwareHints` enables TopologyAwareHints support in AntreaProxy. For AntreaProxy, traffic can be routed to the
+`TopologyAwareHints` enables TopologyAwareHints support in Antrea Proxy. For Antrea Proxy, traffic can be routed to the
 Endpoint which is closer to where it originated when this feature is enabled. Refer to this [link](https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints/)
 for more information about TopologyAwareHints.
 
@@ -111,7 +108,7 @@ for more information about TopologyAwareHints.
 mode determines how external traffic destined to LoadBalancerIPs and ExternalIPs of Services is processed when it's load
 balanced across Nodes. In DSR mode, external traffic is never SNAT'd and backend Pods running on Nodes that are not the
 ingress Node can reply to clients directly, bypassing the ingress Node. Therefore, DSR mode can preserve client IP of
-requests, and usually has lower latency and higher throughput. It's only meaningful to use this feature when AntreaProxy
+requests, and usually has lower latency and higher throughput. It's only meaningful to use this feature when Antrea Proxy
 is enabled and configured to proxy external traffic (proxyAll=true). Refer to this [link](
 antrea-proxy.md#configuring-load-balancer-mode-for-external-traffic) for more information about load balancer mode.
 
@@ -124,7 +121,7 @@ antrea-proxy.md#configuring-load-balancer-mode-for-external-traffic) for more in
 
 ### CleanupStaleUDPSvcConntrack
 
-`CleanupStaleUDPSvcConntrack` enables support for cleaning up stale UDP Service conntrack connections in AntreaProxy.
+`CleanupStaleUDPSvcConntrack` enables support for cleaning up stale UDP Service conntrack connections in Antrea Proxy.
 
 #### Requirements for this Feature
 
@@ -155,7 +152,7 @@ for both Linux and Windows). In v0.11, this feature was graduated to Beta (enabl
 lifted.
 
 In order to support cluster Services as the destination for tracing requests, option `antreaProxy.enable` should be set
-to true to enable AntreaProxy.
+to true to enable Antrea Proxy.
 
 ### Flow Exporter
 
diff --git a/docs/noencap-hybrid-modes.md b/docs/noencap-hybrid-modes.md
index ab0c3b311a9..0c96e121c44 100644
--- a/docs/noencap-hybrid-modes.md
+++ b/docs/noencap-hybrid-modes.md
@@ -9,10 +9,10 @@ are in different subnets, but does not encapsulate when the source and the
 destination Nodes are in the same subnet. This document describes how to
 configure Antrea with the `NoEncap` and `Hybrid` modes.
 
-The NoEncap and Hybrid traffic modes require AntreaProxy to support correct
-NetworkPolicy enforcement, which is why trying to disable AntreaProxy in these
+The NoEncap and Hybrid traffic modes require Antrea Proxy to support correct
+NetworkPolicy enforcement, which is why trying to disable Antrea Proxy in these
 modes will normally cause the Antrea Agent to fail. It is possible to override
-this behavior and force AntreaProxy to be disabled by setting the
+this behavior and force Antrea Proxy to be disabled by setting the
 ALLOW_NO_ENCAP_WITHOUT_ANTREA_PROXY environment variable to true for the Antrea
 Agent in the [Antrea deployment yaml](../build/yamls/antrea.yml).
 For example:
diff --git a/docs/prometheus-integration.md b/docs/prometheus-integration.md
index 25a49b9b33c..47a4daf7a3b 100644
--- a/docs/prometheus-integration.md
+++ b/docs/prometheus-integration.md
@@ -207,15 +207,15 @@ duration of syncing internal-networkpolicy
 #### Antrea Proxy Metrics
 
 - **antrea_proxy_sync_proxy_rules_duration_seconds:** SyncProxyRules duration
-of AntreaProxy in seconds
+of Antrea Proxy in seconds
 - **antrea_proxy_total_endpoints_installed:** The number of Endpoints
-installed by AntreaProxy
+installed by Antrea Proxy
 - **antrea_proxy_total_endpoints_updates:** The cumulative number of Endpoint
-updates received by AntreaProxy
+updates received by Antrea Proxy
 - **antrea_proxy_total_services_installed:** The number of Services installed
-by AntreaProxy
+by Antrea Proxy
 - **antrea_proxy_total_services_updates:** The cumulative number of Service
-updates received by AntreaProxy
+updates received by Antrea Proxy
 
 ### Common Metrics Provided by Infrastructure
 
diff --git a/docs/service-loadbalancer.md b/docs/service-loadbalancer.md
index 7f8235da0db..3210ab5134e 100644
--- a/docs/service-loadbalancer.md
+++ b/docs/service-loadbalancer.md
@@ -36,7 +36,7 @@ LoadBalancer
 ## Service external IP management by Antrea
 
 Antrea supports external IP management for Services of type LoadBalancer
-since version 1.5, which can work together with `AntreaProxy` or
+since version 1.5, which can work together with Antrea Proxy or
 `kube-proxy` to implement Services of type LoadBalancer, without requiring an
 external load balancer. With the external IP management feature, Antrea can
 allocate an external IP for a Service of type LoadBalancer from an
@@ -44,7 +44,7 @@ allocate an external IP for a Service of type LoadBalancer from an
 based on the ExternalIPPool's NodeSelector to host the external IP. Antrea
 configures the Service's external IP on the selected Node, and thus Service
 requests to the external IP will get to the Node, and they are then handled by
-`AntreaProxy` or `kube-proxy` on the Node and distributed to the Service's
+Antrea Proxy or `kube-proxy` on the Node and distributed to the Service's
 Endpoints. Antrea also implements a Node failover mechanism for Service
 external IPs. When Antrea detects a Node hosting an external IP is down, it
 will move the external IP to another available Node of the ExternalIPPool.
@@ -56,7 +56,7 @@ enabled in the `kube-proxy` configuration. For more information about how to
 configure `kube-proxy`, please refer to the [Interoperability with kube-proxy
 IPVS mode](#interoperability-with-kube-proxy-ipvs-mode) section.
 
-If you are using `kube-proxy` iptables mode or [`AntreaProxy` with `proxyAll`](antrea-proxy.md#antreaproxy-with-proxyall),
+If you are using `kube-proxy` iptables mode or [Antrea Proxy with `proxyAll`](antrea-proxy.md#antrea-proxy-with-proxyall),
 no extra configuration change is needed.
 
 ### Configuration
@@ -84,15 +84,15 @@ data:
       ServiceExternalIP: true
 ```
 
-The feature works with both `AntreaProxy` and `kube-proxy`, including the
+The feature works with both Antrea Proxy and `kube-proxy`, including the
 following configurations:
 
-- `AntreaProxy` without `proxyAll` enabled - this is `antrea-agent`'s default
+- Antrea Proxy without `proxyAll` enabled - this is `antrea-agent`'s default
 configuration, in which `kube-proxy` serves the request traffic for Services
-of type LoadBalancer (while `AntreaProxy` handles Service requests from Pods).
-- `AntreaProxy` with `proxyAll` enabled - in this case, `AntreaProxy` handles
+of type LoadBalancer (while Antrea Proxy handles Service requests from Pods).
+- Antrea Proxy with `proxyAll` enabled - in this case, Antrea Proxy handles
 all Service traffic, including Services of type LoadBalancer.
-- `AntreaProxy` disabled - `kube-proxy` handles all Service traffic, including
+- Antrea Proxy disabled - `kube-proxy` handles all Service traffic, including
 Services of type LoadBalancer.
 
 #### Create an ExternalIPPool custom resource
@@ -312,7 +312,7 @@ As MetalLB will allocate external IPs for all Services of type LoadBalancer,
 once it is running, the Service external IP management feature of Antrea should
 not be enabled to avoid conflicts with MetalLB. You can deploy Antrea with the
 default configuration (in which the `ServiceExternalIP` feature gate of
-`antrea-agent` is set to `false`). MetalLB can work with both `AntreaProxy` and
+`antrea-agent` is set to `false`). MetalLB can work with both Antrea Proxy and
 `kube-proxy` configurations of `antrea-agent`.
 
 ### Configure MetalLB with layer 2 mode
diff --git a/docs/traceflow-guide.md b/docs/traceflow-guide.md
index 0a3f553105f..bf4c2c0605b 100644
--- a/docs/traceflow-guide.md
+++ b/docs/traceflow-guide.md
@@ -30,7 +30,7 @@ graph.
 ## Prerequisites
 
 The Traceflow feature is enabled by default since Antrea version v0.11. In order
-to use a Service as the destination in traces, AntreaProxy (also enabled by
+to use a Service as the destination in traces, Antrea Proxy (also enabled by
 default since v0.11) is required.
 
 ## Start a New Traceflow
diff --git a/docs/windows.md b/docs/windows.md
index a2a31197ad0..871de34748e 100644
--- a/docs/windows.md
+++ b/docs/windows.md
@@ -142,10 +142,10 @@ configuration file as the Antrea Proxy `proxyAll` mode is enabled by default.
     # Defaults to "". It must be a host string, a host:port pair, or a URL to the base of the apiserver.
     kubeAPIServerOverride: "10.10.1.1:6443"
 
-    # Option antreaProxy contains AntreaProxy related configuration options.
+    # Option antreaProxy contains Antrea Proxy related configuration options.
     antreaProxy:
-      # ProxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
-      # Therefore, running kube-proxy is no longer required. This requires the AntreaProxy feature to be enabled.
+      # Option proxyAll tells antrea-agent to proxy ClusterIP Service traffic, regardless of where they come from.
+      # Therefore, running kube-proxy is no longer required. This requires the Antrea Proxy feature to be enabled.
       # Note that this option is experimental. If kube-proxy is removed, option kubeAPIServerOverride must be used to access
       # apiserver directly.
       proxyAll: true