Mobile Proxy Configuration on Linux

Environment Variables, and How Far They Reach

Linux has no system proxy setting in the sense the other operating systems mean it. What it has instead is a convention: most software reads the http_proxy and https_proxy environment variables, and respects no_proxy for the hosts that should bypass them. That convention covers a great deal — curl, wget, git, pip, npm, most language runtimes — but it is a convention rather than a rule, and the exceptions are what this guide is really about.

export http_proxy="http://user123:[email protected]:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,::1,.internal.example.com,10.0.0.0/8"

# Some tools read only the upper-case names
export HTTP_PROXY="$http_proxy"
export NO_PROXY="$no_proxy"

Set no_proxy deliberately rather than leaving it empty. Without it, requests to localhost and to internal hostnames are sent to the proxy, which cannot reach them — so a database connection or a health check that worked five minutes ago starts timing out for reasons that look nothing like a proxy problem. Comma-separated, no spaces, and a leading dot matches subdomains.

Note that https_proxy takes an http:// scheme. The scheme says how to reach the proxy, not what protocol the target speaks; the client opens a tunnel and TLS runs end to end inside it. For SOCKS5, prefer the socks5h form, whose trailing h sends DNS resolution through the proxy as well — without it your machine resolves every hostname locally and leaks the entire list of domains you visit to your own network.

The Desktop Proxy Setting and What It Covers

GNOME, KDE and the other desktop environments all offer a network proxy setting, and it looks like the system-wide control that Linux otherwise lacks. It is not. It writes a desktop configuration key, and only applications that deliberately read that key are affected — GNOME Web and a handful of GNOME applications, in practice.

Your terminal does not read it. Neither does anything you launch from your terminal. Setting the desktop proxy and then wondering why curl returns your real address is probably the single most common Linux proxy mistake, and it is entirely reasonable to make: nothing in the interface suggests how narrow its scope is.

apt, sudo and the Tools That Need Their Own File

Two things reliably break a working Linux proxy setup, and both are about the environment not surviving a boundary.

The first is sudo. For security reasons sudo strips most environment variables before running the command, so your carefully exported proxy simply is not there any more. A one-off can be fixed by asking sudo to preserve the environment; a permanent fix means adding the proxy variables to the env_keep list in the sudoers file, which should be edited with visudo rather than directly.

The second is apt, which ignores the environment by design and wants its own configuration. Passing variables through sudo every time works, but a configuration file is more reliable because it applies no matter who runs the command or how.

# apt -- write /etc/apt/apt.conf.d/95proxies
Acquire::http::Proxy "http://user123:[email protected]:8000";
Acquire::https::Proxy "http://user123:[email protected]:8000";

# sudo -- preserve the environment for one command
sudo -E some-command

# sudo -- permanently, via `sudo visudo`
Defaults env_keep += "http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY"

# git, which keeps its own config
git config --global http.proxy "http://user123:[email protected]:8000"

Docker deserves a mention of its own, because it has two separate problems wearing the same name. The daemon needs a proxy to pull images, configured in a systemd drop-in; containers need one passed in as build arguments or environment variables. Configuring one does nothing for the other, which produces the familiar situation where images pull fine and the application inside cannot reach anything.

For software that supports no proxy at all — some older network utilities, a few closed-source tools — proxychains is the standard answer. It preloads a library that intercepts the program’s network calls and routes them through a proxy defined in its own configuration file, and it handles SOCKS5 as well as HTTP. It cannot help with statically linked binaries, since there is nothing to intercept.

Finding Out Which Proxy a Command Is Really Using

Because every tool is configured independently, the useful question is never whether the proxy works — it is which configuration this particular command is reading. Ask the command itself rather than inspecting settings.

env | grep -i proxy
curl -v https://api.ipify.org 2>&1 | head -20

curl https://api.ipify.org ; echo               # through whatever env says
curl --noproxy '*' https://api.ipify.org ; echo # deliberately direct
sudo -E env | grep -i proxy                     # does sudo keep them?

If the endpoint itself is what you want to confirm rather than your configuration, the free PXM2 proxy checker tests it from a browser and reports the detected proxy type and exit country.

Get a Mobile Proxy for Linux

Live PXM2 locations — pick the country you need an exit IP in, and configure it with the steps on this page:

Frequently Asked Questions

Related Mobile Proxy Guides

If your Linux box is a server rather than a desktop, IP whitelisting is usually the better authentication choice — the setup overview covers when to prefer it.

Setup guides

Core mobile proxy guides