Autenticación de proxy
El método para verificar que un usuario está autorizado a usar un endpoint de proxy - mediante credenciales usuario/contraseña o whitelist de dirección IP.
La autenticación de proxy evita el uso no autorizado de los servicios de proxy. Existen dos métodos principales: autenticación por usuario/contraseña y autenticación por whitelist de IP.
La autenticación por usuario/contraseña requiere incluir las credenciales en la URL del proxy: http://username:password@host:port. El servidor proxy valida las credenciales antes de reenviar la solicitud. Este método funciona desde cualquier dirección IP, lo que lo hace flexible para sistemas distribuidos.
La autenticación por whitelist de IP concede acceso según tu dirección IP saliente. Registras tu IP (o rango) con el proveedor, y las solicitudes desde esa IP se permiten sin credenciales. No hace falta usuario ni contraseña en la solicitud - más sencillo de configurar.
Cuándo usar usuario/contraseña: aplicaciones en IPs dinámicas, sistemas distribuidos donde los workers corren en máquinas distintas, o cuando no puedes controlar la IP saliente. Cuándo usar whitelist de IP: servidores con IPs estáticas, configuración más simple para entornos de confianza, y cuando prefieres no almacenar credenciales en el código de la aplicación.
Algunas configuraciones de proxy admiten ambos métodos simultáneamente. Usuario/contraseña es más portable; la whitelist de IP es más simple para despliegues estáticos.
Proving the connection belongs to a customer
A proxy has to decide whether to serve a connection. Two mechanisms are in common use: credentials sent with the connection, or a whitelist of addresses that are trusted without credentials.
With HTTP, credentials travel in a Proxy-Authorization header and a failure returns 407, which is distinct from the 401 a destination would send. With SOCKS5, authentication is part of the protocol handshake, which is why a SOCKS client asks for a username and password before any request is made.
The distinction between 401 and 407 is the single most useful diagnostic in this area. One means the proxy refused you, the other means the destination did, and confusing them sends people to debug the wrong system.
How our products authenticate
Everything uses login and password, and residential can additionally trust your server addresses:
Both mechanisms
Credentials login[_suffixes]:password@proxy.sotaproxy.com:10000
login:password@your-ip:50100 for static
Whitelist register your server address, then connect without
credentials from it (residential lists)
GET/POST /user/residential/whitelist- 407 means we rejected the login. Nine times out of ten a suffix is malformed rather than the password being wrong.
- Some tools cannot send proxy credentials at all. Selenium is the classic case, which is why selenium-wire or a generated extension exists.
- Whitelist servers, not laptops. Home connections change address and the failure looks like a proxy fault.
- Keep credentials working alongside a whitelist so a change of server address does not lock you out entirely.
Authentication confusions
407 is not 401
The first comes from us, the second from the site. They send you to different places to debug.
Credentials in the launch flag rarely work
Chromium-based tools take host and port only. Authentication happens through a separate call.
Whitelisting is not more secure by default
It swaps a secret for a location, which is safer only if the address is exclusively yours.
A password is not per-proxy on residential
One package password serves every session and every suffix combination.
Términos relacionados
Ver esto en práctica
¿Listo para usar autenticación de proxy?
SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.
Empezar