Коротко — это значит, что браузер настроен на использование локального прокси (или PAC‑файла, который отдаёт локальный прокси), а этот локальный прокси в момент ошибки не принимает соединения (нет процесса, слушающего порт). Поскольку вы используете hiddify, очень похоже, что он иногда не запускается/упирается/падает или теряет привязку к порту после сетевых изменений, поэтому браузеры получают “Proxy server refused connection”, тогда как системные соединения (ping, Telegram через системный туннель) идут напрямую и работают.
Куда смотреть и что сделать — пошагово
1) Подтвердить причину в момент ошибки
- Когда появляется ошибка — проверьте, есть ли процесс/порт прокси:
- ss -tulpn | grep -E '127.0.0.1|::1'
- или lsof -i -P -n | grep hiddify
- или netstat -tulpn | grep LISTEN
Ожидаемый результат: должен быть слушающий процесс на порте, который использует браузер (часто 1080/1081/8118/3128 и т.п.). Если ничего не слушает — причина в том, что локальный прокси не запущен.
- Попробуйте подключиться к прокси вручную:
- nc -vz 127.0.0.1 <порт>
- curl -v --proxy http://127.0.0.1:<порт> https://example.com
Если соединение отвергается — прокси не работает.
2) Проверить настройки браузера/системы
- Узнать, откуда браузер берёт прокси:
- env | grep -i proxy
- gsettings get org.gnome.system.proxy mode
- gsettings get org.gnome.system.proxy.http host; gsettings get org.gnome.system.proxy.http port
Возможно, GNOME/система использует PAC, который отдаётся локальным процессом — если PAC недоступен, браузеры переключаются на использование недоступного прокси.
3) Проверить состояние hiddify (или соответствующего клиента)
- systemctl status hiddify.service (или systemctl --user status ...)
- journalctl -u hiddify.service -b --no-pager
- ps aux | grep hiddify
- Просмотрите /var/log/syslog или журнал systemd на предмет крашей, OOM‑килеров:
- journalctl -b -p err
- dmesg | grep -i kill
Если процесс падает — в логах должно быть объяснение.
4) Типичные причины, которые встречаются после апгрейда дистрибутива
- Изменился способ автозапуска (systemd user vs system service), сервис не стартует вовремя или не включён.
- Изменились права/AppArmor/SELinux, которые мешают работе клиента.
- Сетевые события (NetworkManager рестартует сеть) удаляют правила iptables/nftables или переподключают интерфейсы, а hiddify теряет туннель.
- Клиент падает из‑за несовместимости библиотек/обновлённого ядра.
- PAC/локальный прокси запускается поздно (браузер стартует раньше) или падает после пробуждения/смены сети.
5) Быстрые проверки и временные решения
- Когда происходит ошибка — попробуйте отключить прокси в настройках браузера (или в системных настройках) и снова открыть сайт — если заработало, проблема именно в локальном прокси.
- Перезапуск hiddify восстанавливает работу — значит, можно временно автоматизировать: systemctl restart hiddify.service или systemctl --user restart … .
6) Как сделать более надёжно (рекомендуем)
- Если hiddify у вас как systemd‑сервис: в его unit‑файл добавить (в [Service]):
- Restart=on-failure
- RestartSec=5
и в [Unit]:
- After=network-online.target
- Wants=network-online.target
затем systemctl daemon-reload && systemctl enable --now hiddify.service
- Если сервис user‑уровня — аналогично для systemctl --user.
- Настроить скрипт NetworkManager dispatcher или systemd‑таймер, который проверяет и при необходимости перезапускает hiddify при смене сети.
- Обновить hiddify до последней версии (возможно, есть фикс для Ubuntu 26).
- Проверить, не убивает ли процесс OOM‑killer: dmesg/journalctl. Если да — уменьшить потребление или изменить настройки OOM.
- Если проблема в PAC: настроить в браузере fallback (direct) или перенести PAC на внешний сервер.
7) Что прислать мне для более точной диагностики
- Выводы команд (в момент, когда браузер даёт ошибку):
- ss -tulpn | grep -E '127.0.0.1|::1'
- systemctl status hiddify* (или точное имя сервиса)
- journalctl -u <имя_сервиса> -b --no-pager | tail -n 200
- env | grep -i proxy
- gsettings get org.gnome.system.proxy mode
С этими данными смогу подсказать точное место и исправление.
Если хотите, начнём с того, что вы пришлёте вывод systemctl status hiddify и ss -tulpn в момент ошибки.