[tool_call:exec]

🐶 По этому скрину inbound выглядит норм, форвард тут ни при чём — 3x-ui сам делает выход наружу, не через ip_forward. Самый частый косяк с таким симптомом («вижу только IP сервера»): 1) **Settings → Routing** Оставь финальное правило вида `any → freedom` (или `direct`), без `blackhole`/`block`, без странных geo‑правил. 2) В этом inbound снизу нажми **Show** и проверь: **Outbound tag** должен быть `freedom`/`proxy`, а не `block`/`geo_block`. Если можешь — кинь ещё скрины Routing и нижней части inbound (после Show), там сразу будет видно, где его режет.

По этому скрину inbound/Reality выглядит нормально, тут явной ошибки нет. Дальше копать надо: 1) **Settings → Routing** — внизу должно быть `any → freedom` (или direct), без block/blackhole. 2) Внизу этого inbound (после Show) **Outbound tag** тоже должен быть `freedom`/`proxy`. 3) В клиенте режим не «только по списку/сплит», а «через VPN всё». Если можешь — скинь ещё Routing + список outbound’ов, там уже точно станет видно, где режет.

🐶 Так как у тебя сейчас на скрине — с Routing всё ок. Один сервисный rule `api → api` панели, больше ничего, он не режет пользовательский VLESS‑трафик вообще. Если по‑прежнему через ключ видишь только IP сервера, а сайты не открываются — дело не в Routing Rules, а либо в NAT/firewall (перепройди через `go3xui` пункт с фаерволом+NAT), либо в самом клиенте/DNS на устройстве.

[tool_call:exec]

🐶 Здесь всё штатно: `direct → freedom`, `blocked → blackhole`, лишнего нет. Если при таком наборе по ключу всё равно открывается только сам сервер (панель/SSH), значит дело не в Outbound’ах, а в другом месте: 1) Внизу inbound’а проверь, чтобы **Outbound tag = direct**. 2) На вкладке **DNS** оставь нормальные публичные DNS (8.8.8.8, 1.1.1.1 и т.п.), без `localhost`/внутренних IP. 3) В клиенте включи **Global/весь трафик через VPN** и проверь заход по IP, например `https://1.1.1.1`. Если по IP ходит, а по доменам нет — это уже чисто DNS, будем тогда ковырять именно его.