Pregunta Python - ConnectionError: reintentos máximos excedidos


Ocasionalmente obtengo este error cuando mi servidor (llámalo Servidor A) realiza solicitudes a un recurso en otro de mis servidores (todo el Servidor B):

ConnectionError: HTTPConnectionPool(host='some_ip', port=some_port): Max retries exceeded with url: /some_url/ (Caused by : [Errno 111] Connection refused)

El mensaje en la excepción es
message : None: Max retries exceeded with url: /some_url/ (Caused by redirect)
que incluyo porque tiene esa información adicional (caused by redirect).

Como dije, controlo los dos servidores involucrados en esta solicitud, por lo que puedo hacer cambios a uno y / oa ambos. Además, el error parece ser intermitente, en el sentido de que no ocurre siempre.

Información potencialmente relevante: el servidor A es un servidor Python que ejecuta apache y el servidor B es un servidor NodeJS. No soy exactamente un asistente de servidor web, así que más allá de eso, no estoy exactamente seguro de qué información sería relevante.

¿Alguien sabe exactamente lo que significa este error, o cómo investigar una solución? O bien, ¿alguien sabe qué servidor probablemente sea el problema, el que realiza la solicitud o el que lo recibe?

Editar: El error ha comenzado a suceder con nuestras llamadas a recursos web externos también.


11
2018-02-11 18:42


origen


Respuestas:


Obtiene un CONN rechazado en "some_ip" y puerto. Eso es probablemente causado por   - Ningún servidor realmente escucha en esa combinación puerto / IP   - Configuraciones de firewall que envían a Conn Rehusó (¡menos probable es una causa!)   - Tercero: un servidor mal configurado (más probable) u ocupado, que no puede manejar las solicitudes.

Creo cuando: el servidor A está intentando conectarse al servidor B, está recibiendo ese error. (Suponiendo que sea Linux y / o algún derivado de Unix) ¿qué muestra netstat -ln -tcp en el servidor? (Man netstat para entender las banderas - lo que estamos haciendo aquí es - tratando de encontrar qué programas están escuchando en qué puerto). Si eso muestra su servidor B escuchando - iptables -L -n para mostrar las reglas del firewall. Si no pasa nada allí, es una mala configuración de la cola de escucha lo más probable. (http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/023/2333/2333s2.html) o google para escuchar atrasos.

Es muy probable que esto sea un problema de mala configuración en su servidor B. (Nota: un bucle de redireccionamiento como el mencionado arriba, no manejado correctamente, podría terminar ocupando el servidor, por lo que resolverlo también podría resolver su problema)


2
2017-12-14 03:49



Si está utilizando gevent en su servidor python, es posible que deba actualizar la versión. Parece que solo hay algún error con la resolución DNS de gevent.

Esta es una discusión de la biblioteca de solicitudes: https://github.com/kennethreitz/requests/issues/1202#issuecomment-13881265


1
2018-03-08 18:58



Esto se ve como un bucle de redireccionamiento en el lado del nodo.

Menciona que el servidor B es el servidor de nodos, puede crear accidentalmente un bucle de redirección si configura las rutas incorrectamente. Por ejemplo, si usa Express en el servidor B, el servidor de nodo, puede tener dos rutas y suponiendo que mantenga su lógica de ruta en un módulo separado:

var routes = require(__dirname + '/routes/router')(app);
//... express setup stuff like app.use & app.configure
app.post('/apicall1', routes.apicall1);
app.post('/apicall2', routes.apicall2);

Entonces sus rutas / router.js podrían verse así:

module.exports = Routes;

function Routes(app){
    var self = this;
    if (!(self instanceof Routes)) return new Routes(app);
    //... do stuff with app if you like
}

Routes.prototype.apicall1 = function(req, res){
    res.redirect('/apicall2');
}
Routes.prototype.apicall2 = function(req, res){
    res.redirect('/apicall1');
}

Ese ejemplo es obvio, pero es posible que tenga un bucle de redirección oculto en un montón de condiciones en algunas de esas rutas. Comenzaría con los casos extremos, como lo que sucede al final de los condicionales dentro de las rutas en cuestión, ¿cuál es el comportamiento predeterminado si la llamada, por ejemplo, no tiene los parámetros correctos y cuál es el comportamiento de excepción?

Como un lado, puedes usar algo como el nodo-validador (https://github.com/chriso/node-validator) para ayudar a determinar y manejar peticiones incorrectas o publicar parámetros

// Inside router/routes.js:
var check = require('validator').check;

function Routes(app){ /* setup stuff */ }

Routes.prototype.apicall1 = function(req, res){
    try{
        check(req.params.csrftoken, 'Invalid CSRF').len(6,255);
        // Handle it here, invoke appropriate business logic or model, 
        // or redirect, but be careful! res.redirect('/secure/apicall2');
    }catch(e){
        //Here you could Log the error, but don't accidentally create a redirect loop
        // send appropriate response instead
        res.send(401);
    }
}

Para ayudar a determinar si se trata de un bucle de redireccionamiento, puede hacer una de varias cosas, puede usar curl para llegar a la url con los mismos parámetros de publicación (suponiendo que se trata de una publicación; de lo contrario, puede usar chrome, se equivocará en la consola si nota un bucle de redireccionamiento), o puede escribir en stdout en el servidor de nodo o syslog dentro de la (s) ruta (s) ofensiva (s).

Espero que eso ayude, es bueno que hayas mencionado la parte "causada por la redirección", creo que es el problema.

La situación de ejemplo anterior usa express para describir la situación, pero, por supuesto, el problema puede existir usando solo connect, otros frameworks o incluso su propio código de manejador si no está utilizando ningún framework o librería. De cualquier manera, me gustaría acostumbrarme a verificar los parámetros y siempre probar sus casos extremos, me he metido en este problema exactamente cuando tenía prisa en el pasado.


-1
2018-06-15 15:01