ターミナルではプロキシ設定が効くのにデスクトップランチャーでは効かない理由

ターミナルでプロキシをエクスポートします。そこで起動したコマンドはそれを利用します。デスクトップのアイコンをクリックすると、やはり別の経路になります。アイコンはそのターミナルの子にはなっていません。

デスクトップセッションは独自の起動機構でアプリケーションを起動します。それらのプロセスが継承するのはその環境であり、無関係なシェルの中で後から行った編集ではありません。これは違いを説明できますが、アプリケーションのパッケージが欠陥であることを証明するものではありません。

Exec はコマンドの記述であり、シェルスクリプトではない

Desktop Entry 仕様は Exec に対して実行ファイルと引数を定義します。シェル変数の展開やシェルの組み込みコマンドを約束するものではありません。

該当する環境変数を読む外部プログラムであれば、意図的に範囲を限定した起動は次の形にできます。

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

エンドポイントと実行ファイルの両方を置き換えてください。これは起動時の入力を示すもので、任意のアプリケーションがその変数を読む保証ではありません。独自の明示的なプロキシ ポリシーを持つブラウザは、別の設定ソースを選ぶことがあります。Chrome については、プロキシ引数をユーザーランチャーに保存してください。

Exec=export ... と書いて、デスクトップがログインシェルとして解釈することを期待してはいけません。デスクトップエントリの引用規則と対応するフィールドコードにも注意してください。それらはもう一つのパーサーです。

新しいものが起動されたかを確認する

アプリケーションによっては既に実行中のインスタンスに要求を送ります。エントリによっては独自の起動経路を持つ D-Bus アクティベーションを使います。アイコンの新しいクリックは、編集したばかりの Exec 環境を持つ新しいプロセスを確立するものではありません。

要求を行っているインスタンスと、それが実際に持つ設定を特定してください。必要に応じて、制御された新規起動で比較を絞り込めます。意図した環境がそもそも届いていたかを確かめる前に、アプリケーションを再インストールするのは避けてください。