Proxy for Linux: How to Set Up and Use a Proxy on Any Distribution

There are four ways to configure a proxy on a Linux system: shell environment variables, desktop network settings, package manager configuration files, and per-application options. Each method has a different scope, and the scopes do not overlap, a detail behind most proxy setup problems on this platform.
This guide covers Ubuntu, Debian, Fedora, CentOS, and Arch; commands are marked where syntax differs by distro. It also shows how to verify that traffic actually goes through the proxy server, because a silent fallback to a direct connection is the most common failure mode.
What Is a Proxy on Linux and How Does It Work?
A proxy server is an intermediary host: the client sends a request to it, and the proxy forwards that request to the destination. The destination sees the proxy server's IP address, not the client's. This hides the origin of outbound traffic and anonymizes web requests at the application layer.
Linux has no single system-wide proxy switch. Terminal variables, GNOME settings, APT configuration, and Docker settings are independent stores. An application honors only the store it was written to read; nothing enforces routing at the kernel level, so software that ignores these stores sends its network traffic directly.
Two directions exist. A forward proxy handles outbound traffic from clients and is the subject of this article. Reverse proxies such as Nginx or HAProxy sit in front of backend servers, distribute traffic across a network of application instances, balance load, and cache responses. Configuration for the two is unrelated.
HTTP vs SOCKS5: Which Proxy Type to Choose for Linux
An HTTP proxy parses web traffic. Because it understands the protocol, it can cache responses, filter URLs, and modify headers. Encrypted connections pass through it using HTTP CONNECT tunneling, so the proxy sees only the destination host and port, never the payload.
A side benefit shows up on shared networks: one caching proxy in front of many machines cuts repeated downloads, because identical responses come from the local cache.
SOCKS5 operates one layer lower and forwards TCP streams without parsing them. Any protocol can pass through: SSH, database sessions, SMTP. SOCKS5 supports username/password login and UDP association. The trade-off: no caching and no URL rules, because a SOCKS5 endpoint never sees a URL.
A practical difference on Linux is DNS. In curl, the scheme socks5:// resolves hostnames locally, while socks5h:// delegates resolution to the proxy server. Local resolution is a privacy consideration and breaks setups where the target hostname only resolves from the remote side.
Rule of thumb: use SOCKS5 when non-HTTP tools need proxying or when DNS must resolve on the proxy side; choose an HTTP proxy for browsing sessions and scraping pipelines where caching or header control is useful. Commercial proxy servers usually expose both protocols, so the choice is per-tool.
How to Set Up a Proxy on Linux
The four methods below differ in scope: one terminal session, the graphical session, APT/DNF, or a single application. Pick by scope, not habit. Configuring proxy access at the wrong level is why curl works while apt update hangs.

Method 1. Environment Variables (Terminal)
Most command-line tools follow the variable convention. For a temporary setup, proxy values only need to exist in the current shell:
export http_proxy="http://user:pass@203.0.113.10:8080"
export https_proxy="http://user:pass@203.0.113.10:8080"
export no_proxy="localhost,127.0.0.1,.internal.corp"
Case matters. Most utilities read the lowercase names, but some tools (older Java stacks, several Go programs) check only the uppercase forms. Duplicate the values to cover both:
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export NO_PROXY="$no_proxy"
For a SOCKS5 endpoint, set all_proxy instead. The user:pass pair is optional when the provider authorizes your source address rather than credentials:
export all_proxy="socks5h://user:pass@203.0.113.10:1080"
These variables live only in the current session. To make the proxy settings permanent, append the export lines to ~/.bashrc, or put plain KEY=value pairs into /etc/environment for a system-wide effect; that file is parsed by pam_env, not executed as a script.
no_proxy defines the bypass list: hosts that must never be routed through the proxy. Implementations disagree: curl accepts domain suffixes, several Go tools accept CIDR ranges, others match literal strings only. A misconfigured value silently sends internal requests to the proxy server, so test every critical host.
Credentials stored this way appear in ps output and are inherited by every child process; any user or attacker with access to the session can read them. Where the provider offers it, authentication by source IP is safer than a password inside a variable.
System services never read shell startup files. To route one daemon through the proxy, run systemctl edit unit and add a [Service] Environment="HTTPS_PROXY=…" override; it survives updates and mirrors what Docker's daemon does in Method 4.
Method 2. GUI Network Settings (GNOME / KDE)
GNOME: open Settings → Network → Network Proxy, switch to Manual, and enter host and port per service. The same values can be scripted, which helps when provisioning several machines:
gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '203.0.113.10'
gsettings set org.gnome.system.proxy.http port 8080
Automatic mode expects a PAC file URL, a JavaScript function that returns a proxy per destination. Corporate networks distribute these; without one, stay on Manual. KDE keeps its own values under System Settings → Network → Proxy, with an option to apply environment variables instead of manual fields.
Those KDE values land in ~/.config/kioslaverc, a plain file, so the graphical proxy settings can be templated across a fleet with any dotfile manager.
These graphical settings reach only applications built on GLib or KIO: Firefox and GNOME Web read them, command-line tools ignore them. The stores never synchronize, which explains a classic complaint: the browser works while every request from a terminal goes direct. Desktop environments and terminals are configured separately.
Method 3. Package Managers (APT / DNF)
sudo drops these values by default (env_reset in sudoers), so apt update fails even when downloads succeed in the same terminal. Give APT its own configuration file, /etc/apt/apt.conf.d/95proxy:
Acquire::http::Proxy "http://user:pass@203.0.113.10:8080/";
Acquire::https::Proxy "http://user:pass@203.0.113.10:8080/";
On Fedora and CentOS, DNF reads /etc/dnf/dnf.conf: add proxy=http://203.0.113.10:8080, plus proxy_username and proxy_password lines. File-based settings also cover unattended jobs: cron and systemd timers never inherit an interactive environment, which is why installs from scripts need this setup rather than exported variables.
Method 4. Per-App Setup: curl, wget, Git, Docker, Proxychains
curl takes -x on the command line or a proxy = line in ~/.curlrc. wget will use proxy variables from the environment; per-user overrides go into ~/.wgetrc. Both quietly fall back to a direct connection when a variable is empty; verify, do not assume.
Git splits by transport. HTTPS remotes follow http.proxy: git config --global http.proxy http://203.0.113.10:8080. SSH remotes ignore that setting entirely; route them by adding a ProxyCommand line with nc -X 5 to ~/.ssh/config, which pushes the whole SSH session through a SOCKS5 endpoint.
Docker has two separate scopes. Image pulls go through the daemon: create /etc/systemd/system/docker.service.d/http-proxy.conf with an Environment="HTTPS_PROXY=…" line and restart the service. Proxy settings for containers in Docker live in ~/.docker/config.json under "proxies"; Docker injects them into each container via environment variables.
Proxychains covers programs with no built-in support at all. Install it (sudo apt install proxychains4 on Ubuntu), list the endpoint in /etc/proxychains4.conf, then run proxychains4 ./app. It routes TCP through SOCKS5 using LD_PRELOAD, so it fails on statically linked binaries, most Go tools among them.
How to Verify Your Proxy Is Working and Fix Common Errors
On Linux, check the egress address first:
curl https://api.ipify.org
curl --noproxy '*' https://api.ipify.org
The first command must return the proxy address, the second your own. If both match, nothing is proxied: run env | grep -i proxy in the session that launched the tool. GUI applications started from a launcher do not use the proxy variables set in a terminal tab.
An independent check: keep a transfer running and list established connections with ss -tnp. When the peer address is the proxy server rather than the target, traffic really flows through the proxy. Half-applied setups where one program silently connects direct show up immediately.

Frequent errors and their causes:
- 407 Proxy Authentication Required: missing or wrong credentials. URL-encode special characters in the password: @ must become %40, or everything after it is parsed as the host.
- Connection refused: wrong port, or the endpoint speaks a different protocol. Providers often run HTTP and SOCKS5 on separate ports; check the order details.
- Curl works, apt fails: sudo dropped the variables. Use the configuration file from Method 3, or sudo -E for one-off runs.
- Name resolution fails over SOCKS5: switch the scheme to socks5h:// so the proxy resolves hostnames.
- Git clone hangs: http.proxy applies to HTTPS remotes only; SSH transport needs the ProxyCommand from Method 4.
- Everything times out: the endpoint itself is unreachable. Test the TCP path with nc -zv 203.0.113.10 8080 before touching application settings.
When behavior differs between two machines, diff the env | grep i proxy output from both before anything else: mismatched no_proxy entries are the usual cause.
How to Choose a Proxy for Linux
Match the address type to the workload. Datacenter endpoints give the lowest latency and price, which suits performance testing, cache benchmarking, and internal automation. Residential and mobile endpoints cost more and respond slower, but marketplaces and ad platforms rate-limit datacenter ranges far more aggressively during large-scale data collection.
Weigh IPv6 separately: the addresses cost a fraction of IPv4 and Linux tooling handles them natively, but the target must serve AAAA records. Search engines and most SEO endpoints do; many marketplaces still refuse. A mixed pool with IPv4 fallback avoids dead requests.
Location should match the market under analysis: price monitoring for German retailers needs endpoints in Germany, ad verification for U.S. campaigns needs U.S. addresses. Latency grows with distance, and localized content (currency, language, delivery options) renders correctly only from the matching region.
Then check four things against your stack: HTTP and SOCKS5 on the same order; authentication by password and by source address; DNS resolution on the proxy side over SOCKS5; an API for pulling endpoints into scripts. For web scraping, pool size matters more than single-address speed.
Measure instead of trusting listed speeds: time a request through the endpoint against the real target during working hours. Each hop adds its own round trip, so a nearby location often beats a nominally faster distant one. Workloads behind a corporate VPN should confirm the endpoint is reachable from inside.
Proxys.io fits this checklist: individual IPv4 proxy servers from $1.40 per month in 25+ locations, IPv6 from $0.13, plus mobile and residential options, with HTTP(S) and SOCKS5 on every plan. For scraping, SEO monitoring, or ad-verification workloads, try one datacenter IP first and scale after testing.
FAQ
How do I disable a proxy on Linux?
Run unset http_proxy https_proxy all_proxy no_proxy plus the uppercase names, then delete the matching lines in ~/.bashrc and /etc/environment and log back in. Reset GNOME with gsettings set org.gnome.system.proxy mode 'none'. APT, Docker, and Git keep their own settings; clear those separately.
Can I run my own proxy server on Linux?
Yes. Install Squid for HTTP: using Squid, URL rules filter requests, block phishing domains, and enhance security. For SOCKS5, ssh -D 1080 turns any remote server into an endpoint with no additional configuration. Bots scan open ports, so apply best practices: internal interfaces only, credentials, weekly Squid logs review.
If running a proxy server is not worth the maintenance, Proxys.io provides ready endpoints with HTTP(S) and SOCKS5 support, per-order API keys, and a support team that helps with Linux proxy configuration. International clients can pay by card through Stripe; test one location against your workload before committing.