On Linux there is no single place called "the system proxy". The desktop environment, the package manager, the service manager and the container runtime each read proxy information independently of one another . The map below shows which file affects which component.
Configuring one layer does not automatically configure another. That is the source of the classic "apt works but curl doesn't" picture.
1. Environment Variables (Shell Layer)
This is the most common and most portable method. To make it permanent, write it into ~/.bashrc (user only) or /etc/environment (system-wide):
For addresses with authentication the format is http://kullanici:sifre@ip:port/ ; write the special characters in the password using percent encoding (@ → %40).
The change takes effect in a new session; to try it right away, source /etc/environment is not enough, because the file is not a shell script — log out and back in.
2. APT and Snap
apt, because it runs as root, does not see user environment variables. A separate file is required:
/etc/apt/apt.conf.d/95proxy, add:Acquire::http::Proxy "http://185.93.68.14:8080/";- A second line for HTTPS repositories:
Acquire::https::Proxy "http://185.93.68.14:8080/"; - For Snap:
sudo snap set system proxy.http="http://185.93.68.14:8080"
The semicolon at the end of the line is mandatory; if it is omitted, apt returns a "syntax error" and cannot reach any repository.
3. systemd Services
Services such as Docker, containerd and GitLab Runner run in their own environment. The correct method is to add a drop-in file:
sudo systemctl edit docker → [Service] under it: Environment="HTTP_PROXY=http://…" → sudo systemctl daemon-reload && sudo systemctl restart docker.
4. GNOME Desktop
The Settings → Network → Network Proxy section affects only GTK applications. If you want to manage it from the command line: gsettings set org.gnome.system.proxy mode 'manual' and then gsettings set org.gnome.system.proxy.http host '185.93.68.14'. For SOCKS, use the org.gnome.system.proxy.socks schema.
Verification Matrix
Each line tests only one layer. Do not say "the proxy is set up" before running all four.
If you suspect the address itself, first use Proxy Check to measure whether it is alive; whether the problem is in the configuration or in the address — that distinction halves your troubleshooting time.
For the desktop equivalent, see the Windows 11 and macOS guides; for the protocol decision, see the HTTP–SOCKS5 comparison . For server-side workloads, datacenter proxy packages are a good fit.