HTTP 407 ou 401: que inicio de sesión está fallando?
Distingue a autenticación do proxy da do sitio, revisa as cabeceiras correctas e non envíes credenciais ao salto equivocado.
407 pide autenticación no proxy. 401 pídea para o recurso de destino. Unha petición pode atopar ambos, así que identifica quen a solicita antes de dar un contrasinal.
Compara o estado e as cabeceiras de desafío
| Resposta | Cabeceira de desafío | Cabeceira de credenciais | Parte implicada |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Un proxy intermediario |
| 401 Unauthorized | WWW-Authenticate | Authorization | O fluxo de autenticación do recurso de orixe |
O estado é unha primeira pista esencial, pero examina todo o intercambio. O número 407 no texto dunha páxina non equivale a unha resposta HTTP 407 real. Unha páxina de acceso personalizada tamén pode devolver 200 e seguir esixindo autenticación na capa de aplicación.
Por que HTTPS pode fallar con 407 antes de chegar ao sitio
Cando un proxy HTTP normal transporta unha petición HTTPS, o cliente adoita pedir primeiro un túnel CONNECT. O proxy pode esixir autenticación desa petición CONNECT. Se non se completa, a sesión TLS co destino aínda non está establecida polo túnel. Cambiar o token API do sitio dificilmente arranxará esa fase.
Usa unha petición con saída detallada para ver onde aparece o desafío:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Substitúe o punto de escoita local polo teu e le o primeiro desafío no rexistro. Un 407 durante CONNECT precede o TLS do destino; un 401 posterior pode aparecer despois de establecer o túnel correctamente.
Proporciona as credenciais pola interface do proxy
Para un punto de conexión e unha conta dun administrador de confianza, curl pode negociar o esquema de autenticación do proxy e pedir o contrasinal que falte:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Substitúe o punto de conexión e o usuario do exemplo polos datos do servizo que tes permiso para usar. Indicar só o usuario evita poñer o contrasinal directamente na orde anterior. Os métodos admitidos varían coa compilación de curl e o proxy; se falla a negociación, revisa o desafío real e as capacidades da compilación.
A opción de autenticación do proxy é independente da opción de usuario da orixe en curl. Non engadas unha cabeceira Authorization da orixe en lugar de responder ao desafío do proxy. Tampouco reenvíes manualmente cabeceiras de credenciais do proxy a peticións alleas nin as gardes en cabeceiras reutilizadas por toda a aplicación.
Se o proxy segue devolvendo 407
- Confirma que usas o host e o porto do proxy previstos.
- Comproba os esquemas anunciados polo proxy en vez de supoñer Basic.
- Confirma o estado da conta e se o servizo esixe un formato de usuario concreto.
- Revisa a transmisión de caracteres especiais se as credenciais están nun URL.
- Determina se a autenticación empresarial integrada no navegador necesita soporte do contorno de execución ou da plataforma.
- Se os datos do cliente non chegan, pide ao administrador un identificador de petición ou unha entrada do rexistro do servidor sen datos sensibles.
Un 403 ou CONNECT denegado pode ser unha decisión da política de acceso mesmo tras entrar correctamente. Máis intentos de contrasinal non abrirán un destino prohibido.
O HTTPS do destino non protexe todos os intercambios de credenciais do proxy
A autenticación do proxy pode ocorrer antes de establecer o TLS do destino. Se a conexión co propio proxy é sen cifrar e o método expón nela credenciais reutilizables, o destino HTTPS non protexe retroactivamente ese intercambio. Escolle un transporte e unha autenticación axeitados; non envíes contas privadas a un proxy público descoñecido.
Revisa os rexistros detallados antes de compartilos. Aínda que a ferramenta oculte os campos habituais de credenciais, poden quedar usuarios, nomes internos de puntos de conexión, cookies ou outros datos identificativos.