Поиск и устранение неисправностей

Docs

Самые частые проблемы:

Не открываются заблокированные сайты на одном из устройств, хотя на других всё работает? Проверьте настройки DNS на этом устройстве.

В диагностике ошибка FakeIP Status: ! does not work in browser? Скорее всего, дело в DNS на устройстве или «Безопасном DNS» в браузере.

Принципы работы маршрутизации в Podkop #

Маршрутизация Podkop по доменным именам работает корректно только при соблюдении всех следующих условий:

DNS-запросы от клиентского устройства и его программ (браузер, приложения) направляются на роутер с Podkop.
Роутер с Podkop является шлюзом для всего трафика клиентского устройства (или как минимум для подсети FakeIP 198.18.0.0/15).
dnsmasq на роутере обрабатывает все DNS-запросы и настроен на их пересылку на 127.0.0.42. Эту опцию Podkop включает автоматически, если не активирована настройка «Не трогать мой DHCP».
Служба sing-box запущена на роутере, прослушивает сокет 127.0.0.42:53, её конфигурационный файл собран корректно, а удаленные списки доменов (.srs) загружены.
Правила nftables активны, корректно маркируют транзитный трафик из локальной сети и перенаправляют его через tproxy на сокет 127.0.0.1:1602.
Внешнее подключение (прокси-ссылка, Outbound-конфигурация или VPN-интерфейс) полностью работоспособно, и у роутера есть доступ в интернет.

Ключевые выводы для диагностики #

Если на одних устройствах в сети всё работает, а на других — нет, проблема почти всегда кроется в локальных настройках этих устройств. Либо они используют сторонние DNS-серверы, либо их трафик идёт не через роутер с Podkop (например, из-за активного VPN-клиента). См. раздел «DNS на устройствах».
Тесты на вкладке Диагностика корректно работают только из локальной сети. Не стоит анализировать их результаты, если вы подключены к веб-интерфейсу роутера удалённо (например, через проброс портов) — они будут показывать ошибки, даже если всё в порядке.

Диагностика на клиентском устройстве (ПК, смартфон) #

Windows, macOS, Linux — открываем терминал для ввода команд #

Проверка получения FakeIP:
```
nslookup fakeip.podkop.fyi
```
Ожидаемый результат (адрес из диапазона 198.18.0.0/15):
```
Server:		192.168.1.1
Address:	192.168.1.1#53

Name:	fakeip.podkop.fyi
Address: 198.18.x.x
```
- Если в ответе другой IP (например, 64.188.104.86 вместо 198.18.x.x), значит, ваше устройство использует сторонний DNS (его адрес в можно увидеть в строке Server). Решение — в статье «DNS на клиентах».
- Если ответ пустой, а в качестве сервера указан IP роутера, проблема на стороне роутера. Переходите к разделу «Проверка настроек DNS на роутере».
Проверка прохождения трафика через sing-box:
```
curl -v https://fakeip.podkop.fyi/check
```
В выводе вы должны увидеть попытку подключения к FakeIP-адресу (Trying 198.18.x.x...) и в конце получить ответ:
```
{"fakeip": true, "IP": "XX.XX.XX.XX"}
```
- Если curl «зависает» и не может подключиться, значит, трафик не доходит до sing-box. Убедитесь, что роутер с Podkop является шлюзом для вашего устройства, а правила nftables работают
- Если curl подключается через адрес 198.18.*.*, но в ответе "fakeip": false, это указывает на серьёзную проблему в работе sing-box или правил nftables.

А если в терминале всё хорошо, а в браузере нет? Если nslookup и curl в терминале работают правильно, а в «Диагностике» браузера всё равно ошибка ! does not work in browser, откройте ссылку https://fakeip.podkop.fyi/check прямо в браузере. Если она вернет {"fakeip": false, ...}, значит, у вас включен «Безопасный DNS» в браузере, который нужно отключить.

Телевизоры, телефоны и умные устройства без терминала #

Если на устройстве есть браузер с поддержкой JavaScript, откройте в нём веб-интерфейс Podkop (LuCI → Services → Podkop) и перейдите на вкладку «Диагностика». Этой информации, как правило, достаточно для понимания проблемы.

Если браузера нет, отследить DNS-запросы помогут логи dnsmasq, а увидеть, какой трафик идёт через роутер, — утилита tcpdump. Логика та же: если вы не видите DNS-запросов от устройства к dnsmasq, значит, на устройстве настроены внешние DNS-серверы или DoH (DNS over HTTPS).

Проверка настроек DNS на роутере #

Откройте SSH-консоль роутера.

Проверка, какие службы прослушивают порты:
```
netstat -tanp | grep LISTEN
```
Ожидаемый результат должен содержать следующие строки:
```
tcp  ...  127.0.0.42:53    0.0.0.0:*   LISTEN   30933/sing-box
tcp  ...  127.0.0.1:1602   0.0.0.0:*   LISTEN   30933/sing-box
tcp  ...  127.0.0.1:53     0.0.0.0:*   LISTEN   31296/dnsmasq
tcp  ...  192.168.1.1:53   0.0.0.0:*   LISTEN   31296/dnsmasq
```
Это подтверждает, что dnsmasq принимает DNS-запросы на LAN-интерфейсе, а sing-box — на 127.0.0.42. Если это не так, проверьте конфигурации dnsmasq или sing-box.
Проверка конфигурации dnsmasq:
```
uci show dhcp.@dnsmasq[0]
```
В выводе должны присутствовать эти две строки:
```
dhcp.cfg01411c.noresolv='1'
dhcp.cfg01411c.server='127.0.0.42'
```
- noresolv='1' — эта опция запрещает роутеру использовать внешние DNS-серверы (например, от провайдера), которые могут работать в обход Podkop.
- server='127.0.0.42' — эта опция гарантирует, что все DNS-запросы пересылаются напрямую в sing-box.
Если этих настроек нет, или в списке server есть другие адреса, вероятно, у вас включена опция «Не трогать мой DHCP». Убедитесь, что вы настроили её правильно.

Проверка правил маркировки и проксирования трафика #

В SSH-консоли роутера выполните:

nft list ruleset | grep -B3 mark

Вы должны увидеть цепочки правил mangle, mangle_output и proxy, созданные Podkop. Ключевые моменты для проверки:

Счетчики пакетов (counter packets) в правилах для ip daddr 198.18.0.0/15 в цепочке mangle должны быть ненулевыми. Если там нули, значит, трафик от клиентских устройств до роутера не доходит (проблема с DNS или шлюзом на клиенте).
Нет других правил с маркировкой. «Лишние» цепочки с правилами маркировки могут говорить о наличии конфликтующих пакетов (например, неудалённый GetDomains, упомянутый выше vpn-client на прошивках GL.iNet и т.п.)
Сумма пакетов в цепочках mangle и mangle_output должна примерно соответствовать счетчикам в цепочке proxy. Существенно меньшее количество пакетов в proxy также указывает на конфликты правил nftables или о «простоях» sing-box (когда трафик шёл, а sing-box был недоступен)

Проверка работоспособности VPN-интерфейса #

Универсальный способ проверки для WireGuard, Amnezia WG или OpenVPN — команда curl в консоли роутера с указанием интерфейса:

# Замените wg0 на имя вашего интерфейса
curl -v --interface wg0 ifconfig.me

Если туннель работает, команда вернёт внешний IP-адрес вашего VPN-сервера. Если команда «зависает» или выдаёт ошибку, значит, проблема в самом туннеле.

Проверка работоспособности прокси #

Совместимость Podkop со всеми существующими прокси-клиентами и серверами гарантировать невозможно.

Если ваша ссылка работает в другом клиенте (например, NekoBox для Android), но не в Podkop, попробуйте экспортировать конфигурацию из NekoBox в формате JSON и вставить её как Outbound Configuration в Podkop.
Если это не помогает, протестируйте Podkop с 2-3 заведомо рабочими ссылками из Community Sub. Если с ними всё работает, а с вашей — нет, проблема в вашей ссылке или в конфигурации вашего сервера.
В Podkop пока поддерживаются только vless:// и ss:// ссылки. Если вы уверены, что ваша ссылка рабочая (проверили в NekoBox), сгенерируйте временную строку для тестов и отправьте её на email: podkop@itdog.info

Помощь зала #

Если вам не удалось решить проблему самостоятельно, вы можете обратиться в *Официальный чат Podkop`a https://t.me/itdogchat/81758. Рекомендуем именно в нём спрашивать всё про Podkop. В нём сидят разработчики и просто умные люди, понимающие в OpenWrt и схеме FakeIP. В других чатах вы можете столкнуться с дичью и дилетанством.

Если вы не осилили самостоятельно решить проблему и выполнили все пункты:

изучили раздел Поиск и устранение неисправностей
проверили DNS на устройствах
попробовали с заведомо рабочими VLESS из Community sub
на ваших клиентах запрос nslookup fakeip.podkop.fyi отдаёт IP-адрес из подсети 198.18.0.0/15
внимательно прочитали закреп — там только нужное: https://t.me/itdogchat/81758/420321
внимательно прочитали Wiki

но ответа не нашли — переходите к следующему пункту.

📝 Как оформить сообщение: #

Пишите одним сообщением в топике Podkop.

Начните строго с фразы: “я прочитал вики и закреп”

Далее — подробно и по шагам опишите:

Что вы делали.
Что ожидали.
Что произошло.
Как можно воспроизвести ситуацию.

Чем понятнее вы объясните, тем быстрее получится помочь.

⚡ Что обязательно приложить (в том же сообщении) #

Приложите всё ниже перечисленное, строго одним сообщением:

1. Скриншот вкладки “Диагностика”

Делайте скриншот, не фотографию.
Только с проблемного устройства.
Не обрезайте и не затемняйте.

2. Результат глобальной проверки (Global Check)

Кнопка в интерфейсе Подкопа.
Сохраните как .txt.
Все чувствительные данные там уже скрыты.

Если у вас не работает диагностика в LuCi или вы не используете LuCi, Global Check можно вызвать через командную строку:
```
/usr/bin/podkop global_check
```

3. Логи подкопа

Также через «Диагностику» → «Посмотреть логи»
Сохраните как .txt.

4. Лог установки или обновления (только в случае проблем с установкой или обновлением подкопа)

Скопировать весь лог из терминала в котором выполняли.
Сохраните как .txt и прикрепите файлом, не вставляйте текстом.

📑 Перед отправкой убедитесь #

Что у вас установлена последняя версия Podkop (по старым версиям помощь не предоставляется).

Что кэш Luci сброшен, и вы заново открыли веб-интерфейс после обновления.

Что сообщение оформлено всё в одном посте с файлами и скрином.

🔪 Если вы не выполнили всё выше #

Если информации недостаточно, сообщение не по формату, нет фразы я прочитал вики и закреп, или данные отправлены частями — сообщения будут удалены и помощь оказываться не будет.

При повторных нарушениях — предупреждение или мут 🔫

Помните, проект подкоп некоммерческий опенсорс и находится в бета тесте, отвечают вам здесь люди на безвозмедной основе, службы поддержки нет, цените и уважайте труд людей кто вносит свой вклад в развитие проекта.

Корпоративный VPN FakeIP