Axios: Establecer un código / estado para "Error de red"

Creo que tienes razón. Un código de estado tendría sentido.

Como alguien dijo en el n. ° 204, hay algunos casos en los que es imposible detectar errores de red en el navegador, por lo que Axios responde con un error genérico ( new Error('Network error') ). Si desea distinguirlos de las respuestas incorrectas (código de estado! == 2xx o verificación personalizada), creo que la mejor manera es simplemente verificando la propiedad status lugar del mensaje de error. P.ej:

axios.request(options).catch(function(error) {
  if (!error.status) {
    // network error
  }
});

Creo que establecer un código de estado personalizado sería una mala idea (podría causar más confusión) y establecer una propiedad específica no ayudaría en absoluto porque solo tenemos un caso de error.

Por supuesto, en Node.js es más fácil porque tiene acceso al error real y puede verificarlo de acuerdo con la documentación de Node.js.

Ah, entonces se garantiza que cualquier error arrojado por una llamada de Axios 1) tendrá un estado o 2) será un error de red genérico. Supongo que eso es suficiente.

Hasta ahora, no puedo obtener el código de error como 404,500 .., todavía estoy obteniendo un error de red. ¿Cómo solucionar esto?
instance.post ('/ foo', {request_id: 12345})
.entonces (función (respuesta) {})
.catch (función (error) {
console.log (error); // Error de red
console.log (error.status); // indefinido
console.log (código de error); // indefinido
});

Error de red significa que Axios no pudo conectarse a su servidor en absoluto, por lo que no puede obtener ningún código de error del servidor. ¿Quizás probarlo con otra herramienta (curl, cartero o un navegador) para asegurarse de que pueda conectarse?

Puedo conectarme con mi servidor, en realidad devuelve el código de error 404 y con algunas otras llamadas a la API, el servidor devuelve un error interno del servidor 500, pero aún no puedo obtener el código de error de red a través de secuencias de comandos (es decir, console.log ( error.status); // indefinido).

Está en error.response.status .

Tengo este problema. ¿Alguien puede ayudarme por favor?

La respuesta del servidor es 401 pero axios me da esto:

error -> "Error de red"
error.response -> indefinido
error.status -> indefinido

Cuando el error es "error de red", significa que Axios no pudo conectarse a su servidor o, por alguna razón, no obtiene la respuesta de su servidor. De modo que ese error 401 nunca llega a Axios. ¿Quizás publicar una pregunta con algún código de muestra en StackOverflow?

Me encontré con esto al usar AWS API-Gateway. Para cualquiera que vea los mismos problemas, es un problema con los errores 4xx (en mi caso, un 401) que no responde con los encabezados CORS. ¡Pasé horas solucionando este maldito problema! Gracias @ jonathan-stone por señalar mi solución de problemas directamente.

@codygreen Todavía tengo estos problemas y me encontré con este https://forums.aws.amazon.com/message.jspa?messageID=763752

¿Ha encontrado una solución alternativa?

¿Alguien tiene alguna solución a este problema?

Mi problema fue con Jest + Axios. Lo resolví agregando esto a mi package.json:

"jest": {
    "testEnvironment": "node"
}

Esto funciona, aunque parece que no puedo encontrar documentación que lo respalde. Supongo que error.response debería estar vacío en un error de red, de lo contrario es un error de API.

axios.request(options).catch(function(error) {
  if (!error.response) {
    // network error
  } else {
    // http status code
    const code = error.response.status
    // response data
    const response = error.response.data
  }
});

¿Alguien encontró la mejor solución al respecto? La gente de Axios hace algo de ruido :(

También recibí este error hoy, no sé cuál es el problema, este es mi script:

js var url = "http://localhost:8000/"; Axios.get(url).then(function(response){ alert(response) }).catch(function(error){ alert(error) });

http: // localhost : 8000 / devuelve una respuesta JSON, esto no funciona en otros hosts

Podría ser un error de Cors.

Línea 87, ¿se ha configurado como 'Error de red' en el adaptador xhr? ¿Cómo cambiar esto para que se pueda detectar el error?
https://github.com/axios/axios/blob/d7f021b8d4cc50bfa0653011bc02452d234d1255/lib/adapters/xhr.js#L84 -L91

Mi mal, no es un problema, pero el comportamiento esperado debido a la seguridad del navegador. Las respuestas de error XHR ahora reciben un ProgressEvent en los códigos de estado de error.

Tengo el mismo problema. Creo que es un problema con CORS. ¿Alguien ha encontrado una buena solución para esto?

@codygreen , ¿logró solucionar su problema con API Gateway? Ni siquiera puedo averiguar el código de estado de respuesta para ayudarme a depurar más.

El mismo problema general aquí. Para mí definitivamente fue CORS. El navegador estaba haciendo solicitudes de OPCIONES al servidor y no tenía una configuración de controlador para ellas (en el nodo). Axios completaría la solicitud (fallida) con éxito pero con una respuesta indefinida

      return axios.httpClients.server.post('/someUrl, {
        someData:some_data
      }).then(response => {
        console.log(response);
        //the following errors out because response is undefined
        if (response.data && response.data.success === true) {
        }
      }).catch(err => {
           //catch never triggered
            console.log(err)
      });

¿Cuál es su código de respuesta de la respuesta? si se trata de un error de red, al usar la API de Fetch, los navegadores lo registrarán en la consola pero no lo pasarán a JavaScript por razones de seguridad, por lo que el cuerpo está vacío. Consulte FETCH STANDERS , si desea acceder a los errores de red de la respuesta, cambie el código de respuesta HTTP a 200 e incluya el mensaje de error en el cuerpo de la respuesta.

Mi problema fue un problema de dns. Funcionó en cartero pero falló en axios. Probé un rizo para descubrir que también estaba fallando allí. Entonces mi DNS no estaba configurado correctamente. Compruebe eso si se encuentra con este problema.

No estoy seguro de si esto es aplicable a otros casos, pero así es como resolví este mismo problema (considerando que estamos hablando de CORS ).

En el lado de la interfaz , asegúrese de pasar el headers como parámetro en sus solicitudes PUT o POST :

const axiosParams = {
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
    'Accept': 'application/json',
  },
};

axios.put(`${api.url}/like`, axiosParams)
  .then((response) => {
    // ...
  });

Y en el lado del backend , asegúrese de que está utilizando CORS con Express:

// server.js
const express = require('express');
const app = express();

var cors = require('cors'); // Yep, you need to install this
app.use(cors()); // Works 🎉

Refs: aquí y aquí .

Chicos, también estoy luchando con este tema para dejar de fumar. Pero descubrí el problema de mi axios post network createError en el dispositivo Android ahora. La razón del error de red de axios es porque los datos del formulario que pasé a axios contienen un tipo incorrecto de objeto de datos, supongo. He incluido un objeto de imagen (objeto ImagePicker de Expo) como un parámetro de datos de formulario que creo que no acepta axios. Axios solo puede recibir string, float, int o image como param. la imagen no puede pasar como param, no es un tipo de imagen, es un objeto nativo de reacción, lo eliminé e incluyo un campo de imagen como param asignando image.uri al valor de param y luego funciona. Espero que esto ayude a algunas de las personas que puedan encontrar el mismo problema que yo enfrentaba antes.
Al eliminar algunos de los datos de su formulario uno por uno cuando está probando axios Network error, descubrirá cuál es la causa del problema.

~ @codygreen @hammadzz , ¿encontró una solución a esto con Amazon API Gateway? ~

Actualización: si alguien se tropieza con esto con API Gateway y CORS, deberá agregar un encabezado de respuesta access-control-allow-origin a sus respuestas.

Como alguien dijo en el n. ° 204, hay algunos casos en los que es imposible detectar errores de red en el navegador, por lo que Axios responde con un error genérico ( new Error('Network error') ). Si desea distinguirlos de las respuestas incorrectas (código de estado! == 2xx o verificación personalizada), creo que la mejor manera es simplemente verificando la propiedad status lugar del mensaje de error. P.ej:

axios.request(options).catch(function(error) {
  if (!error.status) {
    // network error
  }
});

Creo que establecer un código de estado personalizado sería una mala idea (podría causar más confusión) y establecer una propiedad específica no ayudaría en absoluto porque solo tenemos un caso de error.

Por supuesto, en Node.js es más fácil porque tiene acceso al error real y puede verificarlo de acuerdo con la documentación de Node.js.

Si viene de Google, tenga en cuenta que esta API está obsoleta. Esto es de 2016, v <0,13.

Desea verificar error.response cuando el servidor responda, error.response === undefined para estado fuera de línea y el caso especial de error.code === 'ECONNABORTED' para tiempos de espera.

Actualización: si alguien se tropieza con esto con API Gateway y CORS, deberá agregar un encabezado de respuesta a sus respuestas:

access-control-allow-origin: *

Definitivamente no hagas esto. Establezca los orígenes en consecuencia en lugar de * .

Para mí fue un problema de cors, si estás usando laravel, y defines un

 ->middleware(['auth:api'])

debe agregar todos los demás middleware que necesita a esta ruta explícitamente no se hereda

->middleware(['auth:api','cors']);

También enfrenté este problema, use su dirección IP local en lugar de localhost (por ejemplo, 10.0.0.12:8083). me ha funcionado.

Entonces, si tengo el correcto, el estado 0 de una solicitud de axios parece aparecer en algunos casos. pero no se puede determinar mediante programación exactamente en qué caso se encuentra.

Estos casos incluyen cuando una solicitud de verificación previa de CORS ha fallado y, por lo tanto, nunca se intenta la solicitud real. Debido a esto, el estado 404 no sería apropiado.

Alguien necesita comprarle una cerveza a @joelnet . Esto me salvó el día:

https://github.com/axios/axios/issues/383#issuecomment -308606088

Otras personas pueden tener diferentes problemas, pero eso funcionó para mí.

Recibo este error de forma intermitente. Supongo que no es un problema de CORS.
Mi api / servidor es un servidor .net.
¿Alguien más se enfrenta a esto de forma intermitente?

Tenía este error porque no estaba especificando HTTP o https. Principalmente, el código en sí arroja un error en el protocolo indefinido. Esto debe manejarse o en meta de error, debe incluirse.

Como dijo @ jonathan-stone, no creo que esto se pueda rectificar, porque Axios simplemente no sabe lo que sucedió. Es como enviar a tu amigo a Funyuns y dice que la tienda estaba cerrada. Dice "siempre abierto": por qué se cerró la tienda. ¿Cerraron para siempre (404)? ¿Alguien está enfermo (500)? ¿Se quedaron sin inventario (503)? Él no lo sabe, ¡simplemente están cerrados (error de red)!

Recibía este error al disparar Axios en rápida sucesión contra un servidor Express local que intentaba recuperar diferentes tipos de datos de mi API. No es que Axios no haya reportado un error correcto - no puede - mi servidor Express no respondió con nada porque estaba demasiado ocupado.

Si vuelvo a intentar la solicitud (usando retry-axios del n. ° 164) puedo obtener los datos o tal vez un error real si hay algún problema con el servidor DISPONIBLE.

Para resolver el problema es necesario especificar siempre
Nginx

add_header 'Access-Control-Allow-Origin' * siempre ;

Para resolver el problema es necesario especificar siempre
Nginx

add_header 'Access-Control-Allow-Origin' * siempre ;

No hagas esto. Nunca hagas esto. No desactivaría su firewall solo para dejar pasar una conexión.

Hola chicos, hemos configurado la protección del tamaño de la entidad en nuestro proxy, devuelve un error genérico pero no puedo obtener el código de estado 413 ... ¿es posible de alguna manera?

¿Has probado el objeto response ?
axios.get(url).then(stuff => console.log(Object.keys(stuff.response));

@ComputerCarl, ¿crees que tiene una respuesta exitosa? No lo crea, ya que termina en catch pero puedo probarlo ...

¡Perdón! ¡Mi cabeza estaba en otra parte! Verifique el objeto de captura ...catch(err => console.log(Object.keys(err.response));

Axios doc

Tengo en uno de mis programas;
err.response.data.message;

que envié desde Express;

app.use(function (err, req, res, next) {
  res.status(err.status || 500);
  // this is err.response.data on Axios client
  res.send({ message: 'my custom error' });
});

@ComputerCarl pero error.response no está definido, igual que error.status :) Puedes verlo en la captura de pantalla, ya lo tengo en console.log . Solo error.request es un objeto XMLHttpRequest, como puede ver

Ok ... No sé por qué está recibiendo dos errores (el 413 además del CORS). Sin embargo, si está utilizando Express, debe habilitar CORS;

const cors = require('cors');
// ...
app.use(cors());

Además, como indiqué anteriormente , si el servidor rechaza de plano su solicitud, entonces Axios no sabe qué causó el error. En este punto, estoy perplejo y tendrás que esperar a que alguien más inteligente responda. :-)

@ComputerCarl gracias por intentarlo :-D CORS está bien, tengo muchas llamadas diferentes a la misma API en la aplicación y funcionan bien. Incluso los errores devueltos desde la API puedo manejarlos fácilmente. El problema es con este solo uno cancelado a nivel de proxy.

No sé si esto te ayuda, pero había creado una aplicación que estaba procesando solicitudes. El marco que estaba usando estaba devorando el error Express. Finalmente, después de reenviar explícitamente el error res.send({ message: messageFromProxy }); , pude ver un error y solucionarlo en el cliente.

Buena suerte.

@ jonathan-stone dijo, Error de red significa que Axios no pudo conectarse a su servidor en absoluto, por lo que no puede obtener ningún código de error del servidor.

puede ser que esto ayude a alguien.

error.data ;

@ balwant-sd como puede ver en la captura de pantalla que envié aquí , el navegador reconoce correctamente el código de estado 413, pero axios no

Incluso en la pestaña de red puedo ver el código de estado 413 ...

Como se mencionó anteriormente, un POST de inicio de sesión que devuelve un error 401 devuelve solo 'Error de red' con el código como indefinido en lugar de 401.

Entonces, este error parece ser un error CORS mal configurado que se refleja solo en la pestaña de su red. Tengo el mismo problema que @ketysek , y parece que mi ngnix no está aplicando CORS para esto. Como se mencionó anteriormente, un error de red genérico nunca se convertirá en axios error.response . Aquí me gusta culpar al Backend ... oh, espera, hice eso ...

Hola, también tengo el mismo problema, incluso la solicitud para obtener la respuesta adecuada axios siempre devuelve "Error de red" y va a .catch (función (error) {}); par. ¿Alguien tiene una solución para este problema?

Tuve el mismo problema hoy. Este problema se trata principalmente de que el backend no permite las solicitudes HTTP entre sitios de origen. En mi caso, estoy usando django, así que coloqué la clase corsheaders lo más alto posible en MIDDLEWARE:
MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', //..etc ]
Y creé un CORS_ORIGIN_WHITELIST para permitir solo ciertos orígenes:
CORS_ORIGIN_WHITELIST = [ "http://localhost:8081" , //..etc ]
Esto es para django-cors-headers. Si no es un usuario de django, debe verificar la documentación de su módulo de encabezados de cors favorito.

Como alguien dijo en el n. ° 204, hay algunos casos en los que es imposible detectar errores de red en el navegador, por lo que Axios responde con un error genérico ( new Error('Network error') ). Si desea distinguirlos de las respuestas incorrectas (código de estado! == 2xx o verificación personalizada), creo que la mejor manera es simplemente verificando la propiedad status lugar del mensaje de error. P.ej:

axios.request(options).catch(function(error) {
  if (!error.status) {
    // network error
  }
});

Creo que establecer un código de estado personalizado sería una mala idea (podría causar más confusión) y establecer una propiedad específica no ayudaría en absoluto porque solo tenemos un caso de error.

Por supuesto, en Node.js es más fácil porque tiene acceso al error real y puede verificarlo de acuerdo con la documentación de Node.js.

el problema con este enfoque es que digamos que ejecutamos algún código en axios. then y el código tiene algún error, por ejemplo, "asignación a constante" (que fue mi caso), con el enfoque que mencionaste, obtendremos un error de red para " asignación a constante "

ejemplo de código:

axios(options).then(() => {
  const foo = '';
  foo = 'bar'; // will throw error "assignment to constant"
}).catch(error => {
  if (!error.status) {
    // "assignment to constant" will be considered as network error
  }
})

Utilizo esta función de utilidad para detectar errores de red de la parte inferior de la pila de llamadas (evita identificar errores que no son de axios como errores de red):

function isNetworkError(err) {
  return !!err.isAxiosError && !err.response;
}

Ver https://github.com/axios/axios/pull/1419

Utilizo esta función de utilidad para detectar errores de red de la parte inferior de la pila de llamadas (evita identificar errores que no son de axios como errores de red):

function isNetworkError(err) {
  return !!err.isAxiosError && !err.response;
}

Ver # 1419

Resuelve el problema
Gracias

@mifi ¿ puede mostrar un ejemplo más detallado de cómo está usando isNetworkError para evitar identificar errores que no son axios como errores de red?

Así:

try {
  ...
  some code that calls axios
  ...
} catch (err) {
  if (isNetworkError(err)) return alert(‘check your connection);
  throw err;
}

Si es un error de CORS y usa Serverless, esto puede solucionarlo:

resources:
  Resources:
    # CORS for 4xx errors
    GatewayResponseDefault4XX:
      Type: 'AWS::ApiGateway::GatewayResponse'
      Properties:
        ResponseParameters:
          gatewayresponse.header.Access-Control-Allow-Origin: "'*'"
          gatewayresponse.header.Access-Control-Allow-Headers: "'*'"
        ResponseType: DEFAULT_4XX
        RestApiId:
          Ref: 'ApiGatewayRestApi'

hola, alguien me puede ayudar, 'ERROR DE RED':
https://stackoverflow.com/questions/58717673/axios-sending-network-error- while-status-is-200-ok

Cuando el error es "error de red", significa que Axios no pudo conectarse a su servidor o, por alguna razón, no obtiene la respuesta de su servidor. De modo que ese error 401 nunca llega a Axios. ¿Quizás publicar una pregunta con algún código de muestra en StackOverflow?

También recibo el mismo error, para mí, llega al servidor y respondo con 403 y un JSON, lo que da como resultado el Network Error en el Axios

Puedo ver la respuesta en la pestaña de red del navegador, pero en el bloque de captura err.response no está definido

@ narenderv7 yo también

@WarisR He solucionado esto permitiendo cors en el lado del servidor. Pensé en el problema de Axios, pero en realidad no lo es. Puedo ayudarlo si me deja saber el problema que realmente está enfrentando.

Agregue en el servidor 'Access-Control-Allow-Origin': '*'

@ketysek tengo el mismo error

¿Encontraste una manera de detectar este error?

Hola chicos, tengo un problema de error de CORS en el que recibía una respuesta con el estado 403 (4 * y 5 )Nginx envía el encabezado "Access-Control-Allow-Origin" solo para el estado de respuesta 2 y 3 *.

Resuelvo este problema edito la configuración de nginx desde:
add_header 'Access-Control-Allow-Origin' '*';
para:
add_header 'Access-Control-Allow-Origin' '*' always;

Tengo el mismo problema, lo estoy probando usando axios 0.18.0 y 0.19.0

Pasos:
Hice una solicitud con el token caducado a veces el error. La respuesta llegó correctamente, pero a veces la respuesta de error no estaba definida y el mensaje es 'Error de red'. ¿Por qué sucede esto que es un error de backend o un error en axios?

A veces puede ser causado por los bloqueadores de AD en su navegador ...
Pruebe el modo incognito o private , o descargue un nuevo navegador para probar ...

@ narenderv7 Sí, es un error del lado del servidor. Pero creo que Axios debería poder manejar un error de este caso, ¿verdad?

Necesito distinguir esos dos casos:

• PUBLICAR https://xxx.com/sendMessage net :: ERR_NAME_NOT_RESOLVED
• POST https://xxx.com/sendMessage net :: ERR_INTERNET_DISCONNECTED

Como lo comprobé. el error devuelto por el bloque catch es el mismo en los dos casos anteriores.

Todavía hay un problema:
https://github.com/axios/axios/issues/1296

El error aún existe, si alguien tiene una solución para este problema, compártelo con nosotros.

Utilizo esta función de utilidad para detectar errores de red de la parte inferior de la pila de llamadas (evita identificar errores que no son de axios como errores de red):

function isNetworkError(err) {
  return !!err.isAxiosError && !err.response;
}

Ver # 1419

el error de tiempo de espera también puede coincidir con esas condiciones.