A macOS user conducted an in-depth analysis of Claude application logs following repeated regional availability errors after enabling WireGuard VPN. The review began in the ~/Library/Logs/Claude/ directory, where repeated markers such as app-unavailable-in-region, region_unavailable, and “Claude isn’t available in your region” appeared across web log files.
Using rg searches, the user identified 1,264 lines in the primary log plus 2,891 lines across rotations. Nine specific dates were examined in detail, revealing some errors occurred immediately after Mac wake-ups and others near WireGuard activity. The most notable cluster appeared on September 29, two days before the account restriction.
Despite the timeline correlation, no conclusive proof connected the VPN tunnel to the block. WireGuard’s tunnel-log.bin contained only 2,048 ring-buffer entries, all overwritten by October 3, erasing September data. macOS system containers frequently returned “Operation not permitted” when accessed. The (direct) marker in Claude logs referred solely to internal HTTP proxy selection and did not indicate whether traffic traversed the system VPN.
While troubleshooting Claude, a second problem emerged: several work services became unreachable over WireGuard. amoCRM, TGBooster (including its CDN), and Geekjob all timed out. Comparative curl tests using the physical en0 interface versus the VPN route confirmed that the same destinations returned HTTP 200 when bypassing the tunnel.
Initial attempts to route only Claude domains through the VPN failed because downloads.claude.ai resolved to addresses absent from published network lists. The approach was reversed: WireGuard remained the default route while explicit host routes directed verified work IPs through the local gateway at 192.168.100.1. Ten such routes were added for amoCRM, TGBooster, and Geekjob after verifying each with route get commands.
A temporary PF kill-switch policy was implemented to block direct egress if the tunnel dropped. The ruleset was managed by a launchd service that monitored the WireGuard interface and restored routes. Although initial manual tests succeeded, the service entered a loop on October 5, repeatedly detecting “Own anchor/table changed” and “Own PF hook/order missing,” ultimately severing all connectivity. The service was disabled, original /etc/pf.conf restored, and custom routes reapplied via a separate script.
By October 8, verified work-site addresses remained reachable under active WireGuard while selected Claude endpoints continued through the tunnel. No persistent kill-switch solution survived sleep/wake cycles or network changes, leaving that requirement open.


