Почему настройки прокси работают в терминале, но не в стартере рабочего стола

Вы экспортируете прокси в терминале. Запущенная там команда использует его. Щелчок по значку рабочего стола всё равно даёт другой маршрут. Значок не стал дочерним процессом этого терминала.

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

Exec — это описание команды, а не сценарий оболочки

Спецификация Desktop Entry определяет исполняемый файл и аргументы для Exec. Она не обещает подстановку переменных оболочки или встроенные команды оболочки.

Для внешней программы, которая читает соответствующую переменную среды, намеренно ограниченный запуск может иметь такой вид:

Exec=env https_proxy=http://proxy.example:8080 /path/to/application

Замените и конечную точку, и исполняемый файл. Это демонстрирует входные данные запуска, а не гарантию, что произвольное приложение прочитает эту переменную. Браузер с собственной явной политикой прокси всё равно может выбрать другой источник конфигурации. Для Chrome сохраните его аргумент прокси в пользовательском стартере.

Не пишите Exec=export ... и не ожидайте, что рабочий стол истолкует это как вашу оболочку входа. Учитывайте также правила цитирования и поддерживаемые коды полей записи рабочего стола; это ещё один анализатор.

Проверьте, было ли запущено что-то новое

Некоторые приложения отправляют запрос уже работающему экземпляру. Некоторые записи используют активацию через D-Bus, у которой собственный путь запуска. Новый щелчок по значку не создаёт свежий процесс с только что изменённой средой Exec.

Определите экземпляр, отправляющий запрос, и конфигурацию, которой он действительно владеет. Контролируемый свежий запуск может сузить сравнение, когда это уместно. Избегайте переустановки приложения, пока не установлено, дошла ли до него вообще предполагаемая среда.