A Proxy for snapd Is Separate from One for a Snap App
Configure the daemon fetching snaps separately from applications running inside those snaps.
A working snap install followed by an app that cannot connect involves two different request owners:
| Failed operation | Configuration to investigate |
|---|---|
| Find, download or refresh a snap | snapd's store-access configuration and daemon environment |
| Connect from the installed application | That application's network client, sandbox environment, desktop settings and trust store |
For snapd, use the installation's supported interface. An HTTP endpoint from the HTTP proxy list is a candidate only when public store access may use public proxies. Its proxy.http and proxy.https options are product-specific; their applicability and service environment files must match the deployed system. A terminal export made while running the snap command does not replace the daemon's startup environment.
The upstream unit template includes environment-file inputs, but installed paths and existing values matter. Where appropriate, a systemd drop-in can supply that environment. Loading a changed unit and recreating the daemon process are different steps.
For a running snap app, investigate its own request path. Store success does not establish that it inherited those settings or trusts the same certificates. Name the failed operation first so an application problem does not lead to repeatedly restarting a healthy store-download daemon.