Jakie jest źródło błędu: getaddrinfo EAI_AGAIN?

Mój serwer wyrzucił to dzisiaj, co jest błędem Node.js, którego nigdy wcześniej nie widziałem:

Error: getaddrinfo EAI_AGAIN my-store.myshopify.com:443
    at Object.exports._errnoException (util.js:870:11)
    at errnoException (dns.js:32:15)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:78:26)

Zastanawiam się, czy jest to związane z atakiem DDOS DynDns, który dotknął Shopify i wiele innych usług dzisiaj. Oto artykuł na ten temat.

Moje główne pytanie brzmi: co robi dns.js? Jaka część węzła jest częścią? Jak mogę odtworzyć ten błąd w innej domenie?

Jeśli pojawia się ten błąd w Firebase Cloud Functions, jest to spowodowane ograniczeniami warstwy bezpłatnej ( sieci wychodzące są dozwolone tylko w usługach Google ).

Uaktualnij do planów Flame or Blaze , aby działało.

EAI_AGAIN to błąd przekroczenia limitu czasu wyszukiwania DNS, co oznacza, że ​​jest to błąd łączności sieciowej lub błąd związany z serwerem proxy.

Moje główne pytanie brzmi: co robi dns.js?

• Plik dns.js służy węzłowi do pobierania adresu IP domeny (w skrócie).

Więcej informacji: http://www.codingdefined.com/2015/06/nodejs-error-errno-eaiagain.html

Jest to problem związany z konfiguracją pliku hosts. Dodaj następujący wiersz do swojego pliku hots w Ububtu: / etc / hosts

127.0.0.1   localhost

W systemie Windows: c: \ windows \ System32 \ drivers \ etc \ hosts

127.0.0.1   localhost

Błąd OP określa hosta ( my-store.myshopify.com). Błąd, który napotkałem, jest taki sam pod każdym względem, z wyjątkiem tego, że nie określono żadnej domeny.

Moje rozwiązanie może pomóc innym, których rysuje tutaj tytuł „Błąd: getaddrinfo EAI_AGAIN”

Napotkałem błąd podczas próby udostępnienia aplikacji NodeJs i VueJs z innej maszyny wirtualnej, z której pierwotnie opracowano kod.

Plik vue.config.jsczytał:

 module.exports = {
   devServer: {
     host: 'tstvm01',
     port: 3030,
   },
 };

W przypadku podania na oryginalnej maszynie, wyjście początkowe to:

App running at:
- Local:   http://tstvm01:3030/ 
- Network: http://tstvm01:3030/

Użycie tych samych ustawień na maszynie wirtualnej tstvm07spowodowało bardzo podobny błąd do tego, który opisuje OP:

 INFO  Starting development server...
 10% building modules 1/1 modules 0 activeevents.js:183                              
      throw er; // Unhandled 'error' event
      ^

Error: getaddrinfo EAI_AGAIN
    at Object._errnoException (util.js:1022:11)
    at errnoException (dns.js:55:15)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)

Jeśli nie jest to już oczywiste, zmiana vue.config.jsna przeczytana ...

 module.exports = {
   devServer: {
     host: 'tstvm07',
     port: 3030,
   },
 };

... Rozwiązać problem.

@xerq wskazał poprawnie, oto więcej informacji http://www.codingdefined.com/2015/06/nodejs-error-errno-eaiagain.html

Otrzymałem ten sam błąd, rozwiązałem go, aktualizując plik „hosts” znajdujący się w tej lokalizacji w systemie operacyjnym Windows

C: \ Windows \ System32 \ drivers \ etc

Mam nadzieję, że to pomoże!!

Zacząłem otrzymywać ten błąd (chociaż inny ślad stosu) po wykonaniu trywialnej aktualizacji mojej aplikacji GraphQL API, która jest obsługiwana w kontenerze docker. Z jakiegoś powodu kontener miał trudności z rozpoznaniem usługi zaplecza używanej przez interfejs API.

Po rozejrzeniu się, aby sprawdzić, czy w podstawowym obrazie dockera, z którego budowałem (węzeł: 13-alpine, nawiasem mówiąc), zostały wprowadzone jakieś zmiany, zdecydowałem się wypróbować najstarszą sztuczkę komputerową polegającą na ponownym uruchomieniu ... Zatrzymałem się i uruchomiłem docker pojemnik i wszystko wróciło do normy.

Oczywiście nie jest to znaczące rozwiązanie podstawowego problemu - po prostu publikuję to, ponieważ wyjaśniło to dla mnie problem bez wchodzenia zbyt głęboko w królicze dziury.

Jeśli otrzymujesz ten błąd z kontenera dockera , np. Podczas uruchamiania npm installw kontenerze alpine, przyczyną może być zmiana sieci od czasu uruchomienia kontenera.

Aby rozwiązać ten problem, po prostu zatrzymaj i uruchom ponownie kontener

docker-compose down
docker-compose up

Źródło: https://github.com/moby/moby/issues/32106#issuecomment-578725551

Miałem ten sam problem z AWS i Serverless. Próbowałem z eu-central-1regionem i nie działało, więc musiałem to zmienić us-east-2na przykład.

Jeśli nie otrzymasz tego na localhost ani na produkcji, oznacza to, że musisz uaktualnić swój plan ze względu na ograniczenia bezpłatnej warstwy

aktualizacja npm do najnowszych rozwiązuje ten problem dla mnie.

npm install npm@latest

ten problem jest związany z łącznością sieciową. stąd może być tymczasowy. na stabilnym połączeniu internetowym problem ten był rzadko obserwowany.