Add Temp Diagram and Fix Sidebar Nav (#613)

Author: TechHutTV

public/docs-static/img/manage/reverse-proxy/reverse-proxy-diagram.png

@@ -21,6 +21,10 @@ NetBird Reverse Proxy lets you expose internal services running on peers or behi
 
 When you create a reverse proxy service, NetBird provisions a public domain with an automatic TLS certificate. Incoming HTTPS requests to that domain are terminated at the NetBird proxy cluster, then forwarded through an encrypted WireGuard tunnel to the target peer or network resource running your application. The target service only needs to be reachable within your NetBird network - it does not need a public IP address or open ports.
 
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/reverse-proxy-diagram.png" alt="Reverse proxy traffic flow diagram showing User to Proxy Service (TLS) through WireGuard tunnel to either a NetBird Peer directly or via a Routing Peer to a Network Resource" className="imagewrapper-big"/>
+</p>
+
 You can optionally require authentication (SSO via your configured IdP, password, or PIN) before users can reach the service, ensuring that even publicly accessible URLs remain protected.
 
 ## Concepts
@@ -71,6 +75,10 @@ For example: `myapp.abc123.eu.proxy.netbird.io` where `myapp` is your chosen sub
 {subdomain}.{proxy-domain}
 ```
 
+<Note>
+**DNS records for certificates on self-hosted:** For certificates to work properly, ensure you have the proper records set with your domain name registrar: an **A** record for your NetBird host (e.g. `netbird` → your server IP), plus **CNAME** records for `proxy` and `*.proxy` pointing to that host. See the [self-hosted quickstart](/selfhosted/selfhosted-quickstart#cname-record-for-proxy-domain) for the full table and setup.
+</Note>
+
 For example: `myapp.proxy.mycompany.com` where `myapp` is your chosen subdomain and `proxy.mycompany.com` is the domain configured on your proxy instance(s) via the `NB_PROXY_DOMAIN` environment variable. These domains appear in the domain selector with a **Cluster** badge.
 
 In both deployment types, the available domains are dynamically derived from the proxy instances currently connected to the management server. They are not pre-provisioned - they reflect whichever proxy servers are actively registered.