Usando las variables de entorno HTTP_PROXY / HTTPS_PROXY
Las variables de entorno HTTP_PROXY, HTTPS_PROXY y NO_PROXY son la forma más rápida de enviar el tráfico saliente de un programa a través de un proxy. Aquí se muestra cómo se comportan en curl, wget, Python, Node.js y Docker — y dónde silenciosamente no lo hacen.
Cómo funcionan las variables de entorno del proxy
HTTP_PROXY, HTTPS_PROXY y NO_PROXY son una convención antigua y multiplataforma: muchas herramientas de línea de comandos y bibliotecas HTTP las leen al inicio y dirigen las solicitudes salientes a través del proxy que nombres. El efecto es simple: tu IP real / de origen permanece oculta y el destino ve la dirección de salida del proxy en su lugar.
The naming trips people up. HTTP_PROXY is the proxy used for http:// destination URLs and HTTPS_PROXY for https:// destination URLs — it does not mean "a proxy reached over HTTPS". The scheme inside the value (http:// or socks5h://) is what decides how your client reaches our proxy.
No todas las herramientas honran estas variables, y las que lo hacen no se ponen de acuerdo en los detalles:
| Herramienta | ¿Lee variables de entorno? | Notas |
|---|---|---|
| curl | Sí | minúsculas http_proxy solo para HTTP; ambos casos para HTTPS |
| wget | Sí | honra http_proxy, https_proxy, no_proxy |
| Python requests / urllib | Sí | automático; un argumento por solicitud proxies= anula |
Node.js core fetch / http | No | necesita undici ProxyAgent o global-agent |
| Docker CLI / build | Parcial | pasa a través de --build-arg, -e o config.json |
Ours are datacenter proxies (not residential), so consumer sites may flag them more readily — great for APIs, CI and scraping targets you control, less so for locked-down consumer platforms. Our authenticated SOCKS5 and HTTP proxies take a username and password, so nothing egresses without your credential. For always-on, full-device routing use the WireGuard VPN instead; to try the throwaway public proxy list or price metered access see pricing. More recipes live in the guides, and a full comparison of VPN vs proxy is here too.
Establece las variables en tu shell (curl + wget)
Exporta una vez, luego los comandos ordinarios salen a través del proxy. La autenticación va en línea en la URL como USER:PASS. Configura también la forma en minúsculas: curl solo lee http_proxy en minúsculas para el esquema HTTP.
# HTTP proxy endpoint (port 3128) with inline auth export HTTP_PROXY="http://USER:PASS@proxy.s4m.online:3128" export HTTPS_PROXY="http://USER:PASS@proxy.s4m.online:3128" # curl and some tools only read the lowercase form — set both export http_proxy="$HTTP_PROXY" export https_proxy="$HTTPS_PROXY" # Never send local / internal traffic through the proxy export NO_PROXY="localhost,127.0.0.1,::1,.internal,169.254.169.254" export no_proxy="$NO_PROXY" # Now normal commands go through the proxy curl https://api.ipify.org # prints the proxy exit IP, not yours wget -qO- https://api.ipify.org # One-off, without exporting anything: curl -x http://USER:PASS@proxy.s4m.online:3128 https://example.com # SOCKS5 (port 1080). socks5h makes DNS resolve AT the proxy, # so your origin never leaks the hostname lookup. export ALL_PROXY="socks5h://USER:PASS@proxy.s4m.online:1080" curl https://api.ipify.org
Python y Node.js
Las solicitudes/urllib de Python recogen las variables automáticamente. El http central de Node y fetch() global no lo hacen — debes adjuntar un agente proxy tú mismo.
# --- Python: requests, urllib, pip and httpx honor the env vars ---
import requests
print(requests.get("https://api.ipify.org").text) # proxy exit IP
# Override per-request (this ignores the env vars):
proxies = {
"http": "http://USER:PASS@proxy.s4m.online:3128",
"https": "http://USER:PASS@proxy.s4m.online:3128",
}
requests.get("https://api.ipify.org", proxies=proxies)
# SOCKS5 needs the extra: pip install "requests[socks]"
proxies = {"https": "socks5h://USER:PASS@proxy.s4m.online:1080"}
# --- Node.js (>=18): core fetch does NOT read HTTP_PROXY on its own ---
// import { ProxyAgent, setGlobalDispatcher } from "undici";
// setGlobalDispatcher(
// new ProxyAgent("http://USER:PASS@proxy.s4m.online:3128"));
// const r = await fetch("https://api.ipify.org");
// console.log(await r.text()); // proxy exit IP
//
// To make libraries respect the env vars instead:
// npm i global-agent
// GLOBAL_AGENT_HTTP_PROXY=$HTTP_PROXY node -r global-agent/bootstrap app.jsDocker (construcción y tiempo de ejecución)
Los contenedores no heredan tu entorno de shell. Pasa las variables explícitamente para construcciones y ejecuciones; el daemon que extrae imágenes las lee de su propio archivo de configuración.
# Build-time: forward the proxy into the build
docker build \
--build-arg HTTP_PROXY="http://USER:PASS@proxy.s4m.online:3128" \
--build-arg HTTPS_PROXY="http://USER:PASS@proxy.s4m.online:3128" \
--build-arg NO_PROXY="localhost,127.0.0.1" .
# Runtime: inject into the running container
docker run --rm \
-e HTTP_PROXY="http://USER:PASS@proxy.s4m.online:3128" \
-e HTTPS_PROXY="http://USER:PASS@proxy.s4m.online:3128" \
-e NO_PROXY="localhost,127.0.0.1" \
curlimages/curl https://api.ipify.org
# The Docker daemon itself (image pulls) reads ~/.docker/config.json:
# { "proxies": { "default": {
# "httpProxy": "http://USER:PASS@proxy.s4m.online:3128",
# "httpsProxy": "http://USER:PASS@proxy.s4m.online:3128",
# "noProxy": "localhost,127.0.0.1" } } }Aspectos a tener en cuenta
Codifica en porcentaje las credenciales
Los caracteres especiales en USER:PASS rompen la URL. Codifícalos: @ se convierte en %40, : se convierte en %3A, / se convierte en %2F, # se convierte en %23. De lo contrario, el analizador corta el valor en el lugar incorrecto.
HTTPS_PROXY apunta a URLs https://
Selecciona el proxy para URLs de destino HTTPS — no un proxy alcanzado a través de HTTPS. El esquema en el valor (http:// o socks5h://) es lo que establece cómo te conectas a nuestro proxy.
NO_PROXY es exigente
Separados por comas, sin espacios, coincidiendo con sufijos (.example.com). Los rangos CIDR y el comodín * son soportados por algunas herramientas y ignorados por otras, así que prueba en lugar de asumir.
socks5h vs socks5
Con socks5:// tu máquina resuelve DNS localmente y solo la conexión TCP es proxy. Usa socks5h:// para que la búsqueda del nombre de host también ocurra en el proxy, manteniendo DNS fuera de tu origen.
Las credenciales son visibles localmente
Las variables de entorno aparecen en la salida de ps, el historial de la shell y los registros de CI. Usa una credencial de proxy por cuenta que puedas rotar, y prefiere almacenes secretos en lugar de comprometerlas en un Dockerfile o pipeline.
No todos los clientes los obedecen
El núcleo http y fetch del nodo, además de algunos SDKs, ignoran completamente estas variables. Siempre confirma con un eco de IP como api.ipify.org que el tráfico realmente salió a través de la salida del proxy, no tu IP real.
Preguntas, respondidas
¿Por qué curl ignora HTTP_PROXY pero respeta http_proxy?
Para el esquema HTTP, curl lee deliberadamente solo el http_proxy en minúsculas. El HTTP_PROXY en mayúsculas fue deshabilitado hace años porque los scripts CGI reciben una variable de entorno HTTP_* de los encabezados del cliente, lo que podría secuestrar una configuración de proxy. Para HTTPS y NO_PROXY, curl lee ambos casos. El hábito seguro es exportar ambas formas, en mayúsculas y minúsculas.
¿Cuál es la diferencia entre HTTPS_PROXY y 'un proxy sobre HTTPS'?
HTTPS_PROXY elige qué proxy maneja las solicitudes a URLs de destino https://. No dice nada sobre cómo te conectas al proxy en sí — eso se establece por el esquema en el valor. http://proxy.s4m.online:3128 llega a nuestro proxy HTTP en texto claro CONNECT; socks5h://proxy.s4m.online:1080 llega al punto final SOCKS5. Tu carga útil real a un sitio https permanece cifrada en TLS de extremo a extremo independientemente.
¿Puedo poner una URL SOCKS5 en HTTP_PROXY?
curl acepta socks5:// y socks5h:// en la URL del proxy, pero muchas otras herramientas no. Para portabilidad, usa ALL_PROXY para SOCKS5 o la opción SOCKS de la biblioteca. Prefiere socks5h:// para que DNS se resuelva en proxy.s4m.online:1080 en lugar de filtrar búsquedas desde tu origen.
¿Son estos proxies residenciales?
No. Los proxies s4m son proxies SOCKS5 y HTTP de centro de datos autenticados, facturados por uso. Las IPs de centro de datos son rápidas y confiables para APIs, CI y objetivos de scraping que controlas, pero algunos sitios de consumo detectan y bloquean rangos de centro de datos más fácilmente que los residenciales. No vendemos ni reclamamos IPs residenciales.
¿Configurar estas variables ocultará mi IP real en todas partes?
Solo para programas que realmente los leen. El http central de Node, fetch global, ciertos SDKs y cualquier aplicación que abra sockets en bruto eludirá el proxy y expondrá tu IP real. Después de configurar, verifica con un eco de IP como api.ipify.org, o usa nuestra VPN WireGuard cuando necesites que cada proceso en el dispositivo esté enrutado.
Rutea tus solicitudes a través de s4m
Proxies de centro de datos SOCKS5 y HTTP autenticados, pagados por uso, además de VPN WireGuard a tarifa plana. Sin registros por diseño, primero en RAM, cuentas anónimas. Agrega una IP personal dedicada siempre que necesites una salida estática.
Las personas encontraron esta página buscando
- usando las variables de entorno HTTP_PROXY / HTTPS_PROXY
- Configuraciones de openvpn
- es openvpn seguro
- openvpn
- es autenticación de proxy seguro
- trabajando lista de proxies gratuitos
- ¿Qué es un proxy transparente
- VPN para trabajo remoto
- cómo configurar interruptor de apagado de VPN
- configuración de proxy Puppeteer con autenticación
- proxy http
- ¿qué es proxy para scraping?
Frases de búsqueda reales que esta página responde — los enlaces abren la página que las cubre en profundidad.