Terminal Proxy Integration

Key takeaways

• Proxy integration with the terminal runs through proxy environment variables (http_proxy, https_proxy, all_proxy, no_proxy) that command-line tools read automatically, plus per-tool flags for curl, wget, git, and package managers.
• You can scope a proxy to a single command, a single shell session, or persist it across reboots in a shell profile; on Windows you have set, $env:, and netsh winhttp.
• curl reads lowercase http_proxy only, needs https_proxy set for HTTPS targets, and handles SOCKS5 through socks5h:// for remote DNS; pass credentials with -U to avoid URL-encoding problems.
• Match the Proxy-Cheap product to the job: rotating residential for geo-specific data, datacenter for high-throughput public downloads, static residential or ISP for session-bound CLI work, all reachable with one gateway line.

Most proxy tutorials assume a browser or a Python script. The terminal is different: there is no settings panel, so you configure everything with environment variables, flags, and a few config files. This guide covers every method, the tools that use them, and how to point them at a Proxy-Cheap gateway.

What does proxy integration with the terminal mean?

Proxy integration with the terminal means routing the network traffic of command-line programs through a proxy server instead of sending it straight from your machine. The proxy receives each request, forwards it to the target site through its own IP, and returns the response to your shell.

There are two mechanisms, and most workflows use both:

• Proxy environment variables. Variables like http_proxy, https_proxy, all_proxy, and no_proxy are read automatically by curl, wget, git, apt, pip, and dozens of other tools. Set them once and every compatible program in that shell uses the proxy.
• Per-tool flags and config files. When you want one tool to use a proxy without changing the whole session, you pass a flag (curl -x, wget -e) or edit a tool config (~/.curlrc, ~/.wgetrc, git config).

The terminal approach is precise. You can proxy a single command and leave everything else direct, and on most systems you do not need administrator rights to set a shell variable. That makes it the default choice for automation scripts, CI jobs, remote servers, and headless machines that have no graphical settings at all.

Why route terminal traffic through a proxy?

A direct connection from one IP is fine for a handful of requests. It stops being enough as soon as you script real volume, pull data from several regions, or run jobs from a shared server. Most production command-line work runs through a rotating residential proxy network for three reasons.

1. Reliable connectivity and stable session quality. Many sites rate-limit repeated requests from a single IP and start returning 429 Too Many Requests. Spreading requests across a pool of IPs keeps success rates high across long-running scripts and large download jobs.
2. Accurate geo-specific data. Prices, search results, and product listings differ by country and city. Routing a curl or wget request through an IP in the target market is the only way to capture what a user there actually sees, which matters for localization testing, ad verification, and market research.
3. Compliance with site terms and regional requirements. Public-web data collection at scale should respect rate limits and regional rules. A proxy network with country and city targeting lets you stay inside those boundaries while still gathering the data you need.

If you are new to proxy credentials and dashboards, the step-by-step guide to using residential proxies is a good companion to this article. The rest of this guide assumes you have a proxy host, port, username, and password ready.

Proxy types and the proxy environment variables

Three protocols cover almost all terminal use:

• HTTP proxy. Handles plain http:// requests and tunnels https:// requests with the CONNECT method. The most compatible option across command-line tools.
• HTTPS proxy. The connection between your machine and the proxy itself is encrypted. Supported by curl through the HTTPS-proxy feature.
• SOCKS5 proxy. A lower-level protocol that forwards any TCP traffic. Useful for tools that are not strictly HTTP. With curl, the socks5h:// scheme resolves the target hostname at the proxy rather than locally.

For a deeper comparison of when each fits, see SOCKS5 and HTTP proxies compared. The four environment variables map onto these protocols:

The proxy URL itself is usually http://, even when the request goes to an HTTPS site. The scheme in https_proxy describes how you reach the proxy, not the target.

How to set proxy environment variables in the terminal

Start with a temporary setup that lasts only for the current session. This is the safest way to test credentials before you persist anything.

Linux and macOS (bash or zsh). Export the variables, then confirm them:

# Set the proxy for the current shell session
export http_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"
export https_proxy="$http_proxy"
export all_proxy="$http_proxy"            # used by tools that route every protocol
export no_proxy="localhost,127.0.0.1,.internal.example.com"
 
# Confirm what is set
env | grep -i proxy

To proxy just one command without touching the rest of the session, put the variable in front of the command:

# Only this single request uses the proxy
http_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080" curl https://httpbin.org/ip

Windows (Command Prompt). Use set, and read the proxy URL back with findstr:

set HTTP_PROXY=http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080
set HTTPS_PROXY=%HTTP_PROXY%
set NO_PROXY=localhost,127.0.0.1
set | findstr /I proxy

Windows (PowerShell). Assign the $env: variables for the session:

$env:HTTP_PROXY  = "http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"
$env:HTTPS_PROXY = $env:HTTP_PROXY
$env:NO_PROXY    = "localhost,127.0.0.1"
Get-ChildItem Env: | Where-Object Name -match "PROXY"

On Windows, environment variable names are case-insensitive, so HTTP_PROXY and http_proxy are the same value. On Linux and macOS the case matters, which is the source of a common error covered later.

How to make terminal proxy settings permanent

Once the credentials work, persist them so every new shell picks them up.

Per-user shell profile (Linux and macOS). Append the exports to ~/.bashrc or ~/.zshrc, then reload:

echo 'export http_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"' >> ~/.bashrc
echo 'export https_proxy="$http_proxy"' >> ~/.bashrc
source ~/.bashrc

System-wide (Linux). Add the values to /etc/environment without the export keyword so every user and service inherits them:

http_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"
https_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"
no_proxy="localhost,127.0.0.1"

Per-tool config files. curl and wget each read their own file on every run, which keeps credentials out of your shell history. A ~/.curlrc looks like this:

# ~/.curlrc is read on every curl invocation
proxy = "http://thehub.proxy-cheap.com:8080"
proxy-user = "<your-proxycheap-username>:<your-proxycheap-password>"

Windows (persistent). Write the variables to the user environment so they survive new sessions and reboots:

[Environment]::SetEnvironmentVariable("HTTP_PROXY","http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080","User")
[Environment]::SetEnvironmentVariable("HTTPS_PROXY","http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080","User")

For Windows services that use the WinHTTP stack rather than environment variables, set the machine proxy with netsh:

netsh winhttp set proxy thehub.proxy-cheap.com:8080
netsh winhttp show proxy
netsh winhttp reset proxy

How to use a proxy with curl

curl is the workhorse of terminal networking, and it reads the environment variables above automatically. You can also pass the proxy inline, which is the cleaner pattern for scripts. The complete guide to using curl with a proxy goes further, but these four commands cover the essentials:

# 1. One-off proxy for a single request, credentials in a separate flag
curl -x http://thehub.proxy-cheap.com:8080 \
     -U "<your-proxycheap-username>:<your-proxycheap-password>" \
     https://httpbin.org/ip
 
# 2. Same request, relying on the exported http_proxy and https_proxy variables
curl https://httpbin.org/ip
 
# 3. SOCKS5 with remote DNS (socks5h resolves the hostname at the proxy)
curl -x socks5h://thehub.proxy-cheap.com:8080 \
     -U "<your-proxycheap-username>:<your-proxycheap-password>" \
     https://httpbin.org/ip
 
# 4. Send one host directly, proxy everything else
curl --noproxy "internal.example.com" https://httpbin.org/ip

Two practical notes from real use. First, prefer -U (or --proxy-user) over embedding credentials in the proxy URL. curl keeps the credentials out of URL parsing, which avoids errors when a password contains characters like @, :, or #. Second, https://httpbin.org/ip echoes the outbound IP back to you, so it is the fastest way to confirm the proxy is actually in the path.

How to use a proxy with wget

wget also reads http_proxy and https_proxy, so once the variables are exported a plain wget https://example.com/file.zip already routes through the proxy. When you want to be explicit, pass the settings with -e. The wget with a proxy guide has the full reference; the common patterns are:

# Pass proxy settings inline for this download only
wget -e use_proxy=yes \
     -e http_proxy=http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080 \
     -e https_proxy=http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080 \
     https://example.com/file.zip
 
# Keep credentials in separate flags instead of the URL
wget --proxy-user="<your-proxycheap-username>" \
     --proxy-password="<your-proxycheap-password>" \
     -e use_proxy=yes -e http_proxy=http://thehub.proxy-cheap.com:8080 \
     https://example.com/file.zip

For repeated jobs, set the values once in ~/.wgetrc so you do not retype them:

use_proxy = on
http_proxy = http://thehub.proxy-cheap.com:8080
https_proxy = http://thehub.proxy-cheap.com:8080
proxy_user = <your-proxycheap-username>
proxy_password = <your-proxycheap-password>

Routing other command-line tools through a proxy

Many tools honor the environment variables, but several have their own proxy settings worth knowing.

• git. Set the proxy per protocol; remove it later with --unset.

git config --global http.proxy http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080
git config --global https.proxy http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080
# later: git config --global --unset http.proxy

• npm. Store the proxy in the npm config:

npm config set proxy http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080
npm config set https-proxy http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080

• pip and apt. pip takes a --proxy flag per command; apt reads a config file under /etc/apt/apt.conf.d/:

pip install --proxy http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080 requests

# /etc/apt/apt.conf.d/95proxies
Acquire::http::Proxy "http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080";
Acquire::https::Proxy "http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080";

• proxychains. When a tool ignores proxy variables entirely, proxychains forces its traffic through a proxy. Edit /etc/proxychains4.conf, then prefix any command:

# In the [ProxyList] section of /etc/proxychains4.conf, add one of:
#   http    thehub.proxy-cheap.com  8080  <your-proxycheap-username>  <your-proxycheap-password>
#   socks5  thehub.proxy-cheap.com  8080  <your-proxycheap-username>  <your-proxycheap-password>
 
proxychains4 curl https://httpbin.org/ip
proxychains4 python scraper.py

How to set up Proxy-Cheap proxies in the terminal

Everything above uses placeholder credentials. Here is where the real values come from and how the request actually travels.

A single proxy environment variable or curl flag routes the request through the Proxy-Cheap gateway and back. The exit IP is set by the product you choose.

Proxy-Cheap delivers credentials in standard host:port plus username:password form, generated in the Setup Credentials panel of the dashboard. The endpoint format differs by product:

• Rotating residential uses a single shared hub: thehub.proxy-cheap.com:8080. You choose the country in the dashboard credential generator, so there is no separate US or EU gateway. Every request through the hub gets a new exit IP automatically.
• Static residential, ISP, and datacenter assign a unique IP and port to each proxy you order. Copy the exact host and port from the dashboard and drop it into the same commands.

So a working rotating-residential setup is one export line plus a test:

export http_proxy="http://<your-proxycheap-username>:<your-proxycheap-password>@thehub.proxy-cheap.com:8080"
export https_proxy="$http_proxy"
curl https://httpbin.org/ip      # should print a Proxy-Cheap exit IP, not your own

Three details that save time:

• Use http:// for the proxy scheme. Proxy-Cheap supports HTTP and SOCKS5 across the product line, and HTTP is the most compatible choice for curl, wget, git, and package managers. Reach for socks5h:// only when a tool needs SOCKS.
• IP whitelist authentication is available on static residential, ISP, and datacenter products. If your script runs from a fixed server IP, whitelist it in the dashboard and drop the username and password entirely. This is the cleanest option for CI pipelines and headless servers. The static residential proxies line is built for exactly this kind of stable, session-bound work.
• Keep credentials out of shell history. Put them in ~/.curlrc, ~/.wgetrc, or /etc/environment with sensible file permissions rather than typing them into every command.

How to rotate proxies from the terminal

Rotation works two ways depending on the product:

• Rotating residential rotates at the hub. Because every request through thehub.proxy-cheap.com:8080 gets a fresh IP automatically, you only need the single export line above. Sticky sessions of around 30 minutes are available when you need the same IP across several requests.
• Static residential, ISP, or datacenter give you fixed IPs, so you rotate them yourself by cycling through a list in your script.

This bash loop walks a list of static proxies across a batch of URLs, one IP after another:

#!/usr/bin/env bash
# Cycle a list of static proxies across many requests
proxies=(
  "http://<your-proxycheap-username>:<your-proxycheap-password>@gate-a.proxy-cheap.com:PORT"
  "http://<your-proxycheap-username>:<your-proxycheap-password>@gate-b.proxy-cheap.com:PORT"
)
i=0
while read -r url; do
  p="${proxies[$((i % ${#proxies[@]}))]}"
  curl -s -x "$p" "$url" -o "page-$i.html"
  i=$((i + 1))
done < urls.txt

Choosing between the two comes down to how long you need one IP to last. For a deeper breakdown, read static vs rotating proxies. Rotating residential is the default for high-volume, geo-spread jobs; static residential and ISP proxies win when a workflow needs one consistent IP for hours or days, such as an authenticated API session driven from a script.

Common errors and how to fix them

Most terminal proxy failures fall into a handful of buckets.

1. 407 Proxy Authentication Required. The proxy got no credentials or the wrong ones. Pass them explicitly with curl -U "user:pass" -x host:port, or fix the username and password in your environment variable. Confirm the values against the dashboard.

2. The proxy works for HTTP but not HTTPS. You set http_proxy but not https_proxy, so HTTPS targets go direct or fail. Almost all real traffic is HTTPS, so always set both variables together.

3. Uppercase HTTP_PROXY is ignored on Linux or macOS. curl reads the HTTP variable in its lowercase form only, a safeguard tied to the CGI protocol. Use http_proxy in lowercase. (On Windows the names are case-insensitive, so either works.)

4. SOCKS5 returns "could not resolve host" or the wrong region. Your machine is resolving DNS locally instead of at the proxy. Switch the scheme from socks5:// to socks5h:// so the proxy performs the lookup.

5. sudo apt or sudo curl ignores your proxy. sudo does not pass your environment variables to the elevated command. Run sudo -E curl ... to keep them, or set the proxy in /etc/environment or the apt config so it does not depend on your shell at all.

6. A password with special characters breaks the URL. Characters like @, :, #, and spaces confuse URL parsing. URL-encode them (@ becomes %40, : becomes %3A, # becomes %23) or, better, keep the password out of the URL with curl -U 'user:pass'.

7. no_proxy is not honored. Check the formatting: a comma-separated list with no spaces, and a leading dot (.example.com) to match subdomains. Setting no_proxy="*" sends every host directly.

Which Proxy-Cheap proxy fits your terminal workflow

The right product depends on the shape of the job, not the size of the budget. Match the workflow to the proxy type before you commit.

Pick the product by the shape of the workload: geo-specific data, high-throughput downloads, or session-bound CLI tools.

For high-throughput downloads of public files and documentation, datacenter proxies deliver predictable per-IP pricing and the speed a batch job needs. For geo-specific data, the rotating residential gateway is the default. Whichever you pick, the terminal setup is the same: one gateway line, your credentials, and a curl https://httpbin.org/ip to confirm the exit IP, all on pay-as-you-go pricing with no monthly commitment.