Linux Proxy Setup 2026: curl, APT, Docker and Browser Automation
Linux proxy configuration follows the process making the request. A desktop setting, a shell variable and a Docker daemon setting are separate controls.
Before you configure anything
- Prove the endpoint with one explicit curl request before changing persistent configuration.
- Do not assume every tool reads HTTP_PROXY, HTTPS_PROXY, ALL_PROXY or NO_PROXY the same way.
- Docker image pulls, container traffic and browser-agent traffic can require different settings.
Find the process that opens the connection
| Request owner | Configuration to inspect | Verification |
|---|---|---|
| Desktop browser | Browser or supported desktop settings | IP check in the same browser profile |
| Shell command | Native option or supported environment variables | Request from that command |
| Package manager | Its own proxy and authentication settings | Access the actual repository |
| Docker daemon | Daemon or Docker Desktop proxy settings | Registry request or image pull |
| Container application | Runtime configuration inside the container | Request from that application |
| Remote browser | Hosted session configuration | IP check inside the remote browser |
For a desktop browser, start with the browser's own settings or the desktop environment's supported network-proxy controls. For a command in a shell, use its documented proxy option or environment variables. For a service, configure the service's runtime. For a container, inspect the application inside the container.
These scopes are independent. A browser returning the expected IP does not prove that APT, a background worker or an AI browser session is using the proxy. Identify the process and run a small request from the same environment.
GNOME and KDE expose proxy controls, but applications decide how they use those settings. Chromium's Linux proxy documentation describes its integration with desktop settings. Use the browser guide for browser-specific configuration.
Test HTTP and SOCKS5 with curl
Use an explicit proxy to establish whether the host, port and credentials are correct. The following documentation addresses are placeholders. Replace them before running the commands.
curl --fail --show-error --connect-timeout 10 --max-time 30 \
--proxy http://192.0.2.10:8080 \
--proxy-user proxy-user https://api.ipify.org
curl --fail --show-error --connect-timeout 10 --max-time 30 \
--proxy socks5h://192.0.2.10:1080 \
--proxy-user proxy-user https://api.ipify.org
Curl prompts for a password when only the username is given. socks5h asks the proxy to resolve the destination; socks5 asks curl to resolve it locally. See the curl SOCKS reference.
A timeout before authentication suggests reachability or port issues. An authentication failure means a different stage failed. A response from an IP echo service verifies that request's exit address. It is useful evidence, but it does not establish whether a login-dependent target will accept the session.
Keep TLS verification enabled. An ordinary forwarding proxy should not require --insecure to fetch an HTTPS site. If certificate trust is part of a managed corporate network, use its approved certificate configuration instead of discarding validation.
Use environment variables with explicit scope
Many tools accept proxy environment variables, but their precedence, case handling and SOCKS support differ. Docker's documentation explicitly notes the lack of a single standard. Consult each tool rather than treating a shell export as a universal network policy.
For a command that supports HTTP proxy environment variables, begin with a one-command test. This example has no credentials and uses a placeholder endpoint:
http_proxy=http://192.0.2.10:8080 https_proxy=http://192.0.2.10:8080 no_proxy=localhost,127.0.0.1,::1 curl --fail --show-error --max-time 30 https://api.ipify.org
The https_proxy name refers to HTTPS destination traffic; an http:// proxy URL can carry HTTPS through CONNECT. Do not change it to https:// unless the upstream accepts TLS to the proxy itself.
For automation, inject credentials through the runtime's secret mechanism. Environment variables can still be visible to privileged processes, diagnostics or container inspection. Do not print proxy URLs into CI logs or commit credentials into shell startup files.
A command run through sudo or a background service may receive a different environment. Configure the intended runtime directly. Do not solve that mismatch by broadly preserving every shell variable into privileged commands.
Configure APT separately when needed
Debian's APT HTTP transport documentation covers explicit proxies, environment handling and host-specific choices. A command-local override is useful before writing a persistent configuration.
sudo apt-get -o Acquire::http::Proxy="http://192.0.2.10:8080/" -o Acquire::https::Proxy="http://192.0.2.10:8080/" update
This checks repository access through a sample HTTP endpoint. Replace the host and port; it does not install packages. For authenticated repositories or proxies, use APT's documented authentication configuration and restrictive file permissions rather than exposing credentials in shared scripts.
Do not generalize APT's behavior to every package manager. pip, npm, Git and distribution-specific managers have their own options, configuration files and certificate handling. Start with their native proxy support and record where you set it so it can be removed cleanly.
If a package operation fails while curl succeeds, compare destination, authentication and TLS trust. A successful request to one host does not prove the proxy permits every repository or that the package manager trusts the required certificates.
Separate Docker pulls from container traffic
Docker Engine's daemon makes registry requests such as image pulls. Applications inside a container make their own requests. Daemon proxy configuration and container proxy variables are documented separately. Docker Desktop uses its own settings.
For a containerized worker, supply the proxy configuration to that worker when you create it. A host shell export does not automatically become an application environment inside an already running container. Verify the exit IP from the same container and runtime that perform the job.
Do not bake proxy credentials into a Dockerfile with ENV. That can persist them into images and derived containers. Proxy build arguments and runtime configuration serve different purposes; follow the documented secret-handling approach for the build system you use.
A local proxy bound to 127.0.0.1 on the host is also not automatically reachable as 127.0.0.1 inside a container. Loopback there refers to the container's own network namespace. Select an intentional reachable address and restrict access rather than opening the proxy to every network interface.
Use proxychains only for compatible programs
proxychains-ng hooks networking functions in dynamically linked programs and documents TCP-only support. Use it when a compatible command lacks an adequate native proxy option. It is not a packet-level replacement for all Linux networking.
Create a separate configuration so a distribution's example Tor entry does not accidentally join your route. A minimal example for one authenticated SOCKS5 endpoint is:
strict_chain
proxy_dns
[ProxyList]
socks5 192.0.2.10 1080 proxy-user proxy-password
Save real credentials only in a user-readable configuration file. Substitute your endpoint, then run a suitable command with an explicit file:
chmod 600 ./proxychains-test.conf
proxychains4 -f ./proxychains-test.conf curl --max-time 30 https://api.ipify.org
The executable may have a different name in your distribution. Test without other active proxy settings so the request is not proxied twice. Static binaries and programs that bypass the intercepted functions may not work as expected. UDP and ICMP tests do not establish success for this TCP wrapper.
Configure AI tooling where the fetch happens
For a local Playwright browser, set the browser or context proxy explicitly. Browser Use's browser parameters expose a separate proxy configuration. Neither is guaranteed to inherit the network settings used by a model SDK.
For Claude Code, the current network documentation supports HTTP/HTTPS proxy configuration and says SOCKS proxies are unsupported. Use the documented endpoint type. A tool launched by the assistant can still have separate networking requirements.
An MCP server or an n8n worker may run locally, in a container or on another host. Set the proxy in the component that fetches the website, then test there. A cloud browser's route is configured with its provider; a host-level Linux setting cannot choose that remote browser's exit network.
Our browser automation example and MCP integration guide provide the next steps. Keep a stable endpoint for a browser session and handle reconnection deliberately rather than rotating on every unrelated request.
Verify and roll back without guessing
Record the command, runtime, proxy protocol and client version. Check a direct baseline if your environment permits it, then the proxied request. For persistent jobs, test reconnecting and observe whether a failure stops the job or falls back to direct access.
When you undo a setup, remove it at the same layer where you added it: command environment, user configuration, service environment, Docker settings or desktop controls. Stopping a local listener alone can leave clients pointed at a dead port.
For web scraping, keep authorization, request rate and session state in the test plan. A correct route does not grant access to a restricted destination. For mobile proxy infrastructure, confirm rotation and endpoint features independently of the Linux client.
Sources and review scope
This guide was checked against the documentation below on October 11, 2026. Software behavior depends on the installed version, operating system and proxy service. Configuration examples are illustrative; this is a documentation review, not a benchmark of every client.
Frequently asked questions
Continue with your device
Protocol basics, operating-system setup and client choices in one series.
Related workflows
Pass the proxy directly to the browser runtime.
Locate the process that fetches the target resource.
Choose an upstream for permitted collection.
Understand the network behind the endpoint.