@Deelon 

hello

Fix 1: Switch to Policy-Based Routing (VPN Client Feature)
Instead of relying on the WireGuard AllowedIPs parameter to handle the routing, use the router’s built-in VPN Client settings to control which traffic goes where.

1. On your Client Router (192.168.0.1), go to Advanced > VPN Client.
2. Do not assign your devices to the WireGuard profile in the general "VPN Access" list (leave them off so they keep regular internet access).
3. Look for Policy Routing (or Advanced Routing/Static Routes depending on the exact firmware sub-menu layout).
4. Add a Static Route:
   • Destination Network: 192.168.1.0
   • Subnet Mask: 255.255.255.0
   • Gateway/Interface: Select your WireGuard VPN Interface instead of the WAN port.

This allows your local devices to keep their standard internet gateway for 0.0.0.0/0 traffic, while manually pushing 192.168.1.0/24 traffic through the WireGuard tunnel.
Fix 2: Flip the Server/Client Roles
If the Server router (192.168.1.1) has better configuration options, or if you can configure its Client Access type, changing how the handshake initiates might help.
On TP-Link WireGuard Server configurations, there is a setting called Client Access. If it is set to "Internet and Home Network", it explicitly tells connected peers to route everything through it. If you have administrative control over the Server router, ensure the profile generated for the Client router is restricted to "Home Network Only".
Fix 3: Handle the Routing at the OS Level (If possible)
If the primary devices needing access to the remote site are PCs or servers:

1. Turn off the VPN Client feature on the Archer router entirely.
2. Install the standalone WireGuard application directly onto those specific computers.
3. Import the configuration file into the OS app. The official WireGuard software handles AllowedIPs flawlessly and will correctly split-tunnel the traffic.