docs: standardize on "NetBird client" over "agent" for the client software (#940)

* docs: standardize on "NetBird client" over "agent" for the client software * docs: address review feedback - fix "a software" grammar and use lowercase "NetBird client" - define routing peer as a peer whose client bridges, keeping peer and client distinct - correct kernel-space claim: the kernel WireGuard data path is what runs in the kernel - clarify which address the application uses to reach the SOCKS5 proxy from a separate container
2026-10-18 03:29:03 +02:00 · 2026-08-21 13:24:33 +02:00
parent d60d579197
commit 62baad95a1
28 changed files with 50 additions and 47 deletions
@@ -226,7 +226,7 @@ Understanding policy directionality is essential for implementing Zero Trust acc

 ### Policies Between Peers

-When both source and destination are peers running the NetBird agent, you have full control over directionality:
+When both source and destination are peers running the NetBird client, you have full control over directionality:

 **Unidirectional:** Traffic flows only from source to destination. In the NetBird UI, this appears as a single arrow (→).

@@ -277,7 +277,7 @@ Direction: ALWAYS Source → Destination (cannot be bidirectional)

 **Why is this always unidirectional?**

-Network resources don't have the NetBird agent installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network.
+Network resources don't have the NetBird client installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network.

 Think of it this way:

@@ -115,7 +115,7 @@ The current version of NetBird tracks a wide range of network changes that occur

 </details>

-Future versions will also support connection events that occur in NetBird agents (e.g., peer A connected to peer B).
+Future versions will also support connection events that occur in NetBird clients (e.g., peer A connected to peer B).

 <Note>
    The `unknown` name or `unknown@unknown.com` email address may be displayed in the activity event store if the encryption key has been corrupted or lost. This issue is most relevant for self-hosted setups. In this case, the events returned by the API could show `unknown@unknown.com` for the email address field and `unknown` for the name field.
@@ -194,7 +194,7 @@ In this example, peers in `berlin-office` use `aws-nb-europe-router-az-a` to acc

 Disable masquerade when you need source IP transparency or want to manage routing on your external network. The routing peer forwards packets with the original NetBird peer IP intact.

-This requires configuring your external network router with a return route to your NetBird network through the routing peer. Devices without the agent can then communicate with your NetBird peers.
+This requires configuring your external network router with a return route to your NetBird network through the routing peer. Devices without the client can then communicate with your NetBird peers.

 <p>
    <img src="/docs-static/img/manage/network-routes/concepts/netbird-network-routes-masquerading.png" alt="Routes without masquerading" className="imagewrapper-big"/>
@@ -3,11 +3,11 @@ import { Tiles } from '@/components/Tiles'

 # How Routing Peers Work

-A routing peer is a NetBird agent that bridges your overlay network to private networks and resources that do not run the agent. This page covers what routing peers are, how traffic flows through them, the requirements they impose on the host, how high availability and access control behave, and how to harden them.
+A routing peer is a NetBird peer whose client bridges your overlay network to private networks and resources that do not run the client. This page covers what routing peers are, how traffic flows through them, the requirements they impose on the host, how high availability and access control behave, and how to harden them.

 ## What is a routing peer

-A routing peer is a NetBird peer installed inside a private network that forwards traffic between the NetBird overlay and resources that cannot or should not run the agent themselves. It is the bridge between your Zero Trust mesh and the LANs, VPCs, datacenter networks, or individual hosts you need to reach.
+A routing peer is a NetBird peer installed inside a private network that forwards traffic between the NetBird overlay and resources that cannot or should not run the client themselves. It is the bridge between your Zero Trust mesh and the LANs, VPCs, datacenter networks, or individual hosts you need to reach.

 A single peer can serve multiple roles at once. The same machine can be a client peer, a routing peer for one or more networks, and an exit node simultaneously.

@@ -15,10 +15,10 @@ Because routing peers are typically headless servers, register them with [setup

 ## When to use a routing peer

- **Site or LAN access.** NetBird peers need to reach resources on a remote subnet, office network, datacenter, or cloud VPC without installing the agent on every host.
+- **Site or LAN access.** NetBird peers need to reach resources on a remote subnet, office network, datacenter, or cloud VPC without installing the client on every host.
 - **Domain-based access.** Traffic must be routed by FQDN or wildcard domain to services whose IPs change.
 - **Exit node.** All internet-bound traffic from a group of peers must egress through a controlled location.
- **Kubernetes.** Pods or services need to be reachable from NetBird peers without putting an agent on every node.
+- **Kubernetes.** Pods or services need to be reachable from NetBird peers without putting the client on every node.

 ## Networks vs Network Routes

@@ -52,11 +52,11 @@ The walkthrough below describes the **Linux kernel-mode** path, where forwarding

 ### Operating system

-Linux, Windows, macOS, FreeBSD, Android, tvOS, and Docker peers can act as routing peers. Linux is the most common production choice because the agent runs in kernel space and integrates with native kernel firewalls (`nftables` / `iptables`). On other platforms the forwarding path runs in userspace.
+Linux, Windows, macOS, FreeBSD, Android, tvOS, and Docker peers can act as routing peers. Linux is the most common production choice because it uses the kernel WireGuard data path by default and integrates with native kernel firewalls (`nftables` / `iptables`). On other platforms the forwarding path runs in userspace.

 ### IP forwarding

-The agent enables IP forwarding automatically on Linux. If the agent cannot modify sysctl on its own, set it yourself on the host and persist it:
+The client enables IP forwarding automatically on Linux. If the client cannot modify sysctl on its own, set it yourself on the host and persist it:

 ```bash
 # Runtime
@@ -167,7 +167,7 @@ For the full setup — the file-server scenario, the commands, the Active Direct

 ### Directionality is forced for routed traffic

-Policies whose destination is a network resource are always unidirectional from source to destination. The resource has no agent and cannot initiate connections back through the overlay. The bidirectional toggle is disabled in the UI for these policies.
+Policies whose destination is a network resource are always unidirectional from source to destination. The resource has no client and cannot initiate connections back through the overlay. The bidirectional toggle is disabled in the UI for these policies.

 ### Network Routes default-allow caveat

@@ -175,7 +175,7 @@ The return route points at one peer, so it has to follow whichever routing peer
 Two steps:

 1. **Give the routing peers different metrics**, so the active peer is the same one for every client. With equal metrics each client picks its own by latency, and then no single next hop is correct for all of them. See [High availability](/manage/networks/how-routing-peers-work#high-availability).
-2. **Make the route's next hop follow the active peer.** Either a shared virtual IP across the peers (VRRP, using `keepalived` on Linux, which needs them on the same subnet), or a router that moves the route when a health check fails. The mechanism lives outside NetBird. Whichever you choose, make its health check reach a destination through the tunnel rather than testing the peer itself: a routing peer whose agent is running and whose WireGuard interface is present can still be unable to forward, and neither NetBird nor an interface check notices.
+2. **Make the route's next hop follow the active peer.** Either a shared virtual IP across the peers (VRRP, using `keepalived` on Linux, which needs them on the same subnet), or a router that moves the route when a health check fails. The mechanism lives outside NetBird. Whichever you choose, make its health check reach a destination through the tunnel rather than testing the peer itself: a routing peer whose daemon is running and whose WireGuard interface is present can still be unable to forward, and neither NetBird nor an interface check notices.

 <Warning>
 Do not point the return route at both peers at once, as two static routes or an equal-cost pair. Replies reaching the peer a client is not using are silently discarded, so both ends look healthy while traffic fails.
@@ -4,7 +4,7 @@
 Whether you have a network for personal use or manage your company's corporate network, you'd probably want to add machines
 (or peers in NetBird's terms) to your network.

-NetBird peer is a machine that runs the [NetBird agent](/about-netbird/how-netbird-works#client-application)
+NetBird peer is a machine that runs the [NetBird client](/about-netbird/how-netbird-works#client-application)
 and is connected to the network. NetBird peer can be a virtual machine running in the cloud like AWS or Google Cloud,
 an Android or iOS device, a personal laptop, a single-board computer like Raspberry Pi, a docker container, or even a router.

@@ -5,7 +5,7 @@ import {Note, Warning} from "@/components/mdx";
 The Automatic Updates feature allows the NetBird client to notify users when a new version is available and prompt them to install it. This ensures that users always have the latest features and security patches without needing to manually download and install updates.

 <Note>
-    Minimum supported agent version: <strong>v0.61.0</strong>.
+    Minimum supported client version: <strong>v0.61.0</strong>.
    This or higher version must also be installed on the peers you need to Automatically Update.
 </Note>

@@ -69,7 +69,7 @@ A target defines where proxied traffic is sent within your NetBird network. Ever

 | Type | Description | How to select |
 |------|-------------|---------------|
-| **Peer** | A machine running the NetBird agent directly | Select from the peer list |
+| **Peer** | A machine running the NetBird client directly | Select from the peer list |
 | **Host** | A network resource identified by an IP address | Select from your network resources |
 | **Domain** | A network resource identified by a domain name | Select from your network resources |
 | **Subnet** | A network resource within a CIDR range | Select from your network resources, then specify an IP within the range |
@@ -96,7 +96,7 @@ The following API fields relate to IPv6:

 ### Peers report no IPv6 address after enabling the setting

-Peers only get an IPv6 address if they belong to at least one group listed in **IPv6 Enabled Groups** and if the client version supports the IPv6 overlay capability (v0.71.0+). Older agents don't advertise the capability, so management leaves them out of IPv6 distribution: they don't get the address on their interface, and other peers don't receive AAAA records or IPv6 firewall rules for them.
+Peers only get an IPv6 address if they belong to at least one group listed in **IPv6 Enabled Groups** and if the client version supports the IPv6 overlay capability (v0.71.0+). Older clients don't advertise the capability, so management leaves them out of IPv6 distribution: they don't get the address on their interface, and other peers don't receive AAAA records or IPv6 firewall rules for them.

 ### Routing peer has an IPv6 address but traffic doesn't reach the backend