Poseemos la mejor información que descubrimos por todo internet. Esperamos que te sirva de ayuda y si deseas comentarnos alguna mejora siente la libertad de hacerlo..

Solución:

Los problemas fueron:

1. IPV6 habilitado
2. Servidor DNS incorrecto

Así es como lo arreglé:

Inhabilitación de IPV6

• terminal abierta
• Escribe su e ingrese para iniciar sesión como superusuario
• Ingrese la contraseña raíz
• Escribe cd /etc/modprobe.d/ para cambiar de directorio a /etc/modprobe.d/
• Escribe vi disableipv6.conf para crear un nuevo archivo allí
• prensa Esc + i para insertar datos en el archivo
• Escribe install ipv6 /bin/true en el archivo para evitar cargar módulos relacionados con IPV6
• Escribe Esc + : y luego wq para guardar y salir
• Escribe reboot para reiniciar fedora
• Después de reiniciar, abra la terminal y escriba lsmod | grep ipv6
• Si no hay resultado, significa que deshabilitó correctamente IPV6

Agregar servidor DNS de Google

• terminal abierta
• Escribe su e ingrese para iniciar sesión como superusuario
• Ingrese la contraseña raíz
• Escribe cat /etc/resolv.conf para verificar qué servidor DNS usa su Fedora. En su mayoría, esta será la dirección IP de su módem.
• Ahora tenemos que encontrar un servidor DNS potente. Afortunadamente, hay un servidor DNS abierto mantenido por Google.
• Vaya a esta página y descubra cuáles son las “Direcciones IP DNS públicas de Google”
• hoy esos son 8.8.8.8 y 8.8.4.4. Pero en el futuro eso puede cambiar.
• Escribe vi /etc/resolv.conf para editar el resolv.conf expediente
• prensa Esc + i para insertar datos en el archivo
• Comente todas las cosas en el archivo insertando # al comienzo de cada línea. No borre nada porque puede ser útil en el futuro.

• Escriba debajo de dos líneas en el archivo

  servidor de nombres 8.8.8.8
  servidor de nombres 8.8.4.4

  -Escribe Esc + : y luego wq para guardar y salir
• Ahora ha terminado y todo funciona bien (no es necesario reiniciar).
• Pero cada vez que reinicie la computadora, su /etc/resolv.conf será reemplazado por defecto. Así que te dejaré encontrar una manera de evitar eso.

Aquí está mi publicación de blog sobre esto: http://codeketchup.blogspot.sg/2014/07/how-to-fix-curl-6-could-not-resolve.html

¿Quizás tiene algunas reglas SELinux muy extrañas y restrictivas?

Si no, intente strace -o /tmp/wtf -fF curl -v google.com y tratar de detectar desde /tmp/wtf archivo de salida lo que está pasando.

Tengo hoy un problema similar. Pero más raro.

• anfitrión – obras host pl.archive.ubuntu.com
• dig – funciona de forma predeterminada y en todos los demás DNS dig pl.archive.ubuntu.com, dig @127.0.1.1 pl.archive.ubuntu.com
• rizo – ¡no funciona! pero para algunas direcciones lo hace. ¡EXTRAÑO! Lo mismo en Ruby, APT y muchos más.

$ curl -v http://google.com/
*   Trying 172.217.18.78...
* Connected to google.com (172.217.18.78) port 80 (#0)
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Location: http://www.google.pl/?gfe_rd=cr&ei=pt9UWfqXL4uBX_W5n8gB
< Content-Length: 256
< Date: Thu, 29 Jun 2017 11:08:22 GMT
<


302 Moved
The document has moved
here.

* Connection #0 to host google.com left intact

$ curl -v http://pl.archive.ubuntu.com/
* Could not resolve host: pl.archive.ubuntu.com
* Closing connection 0
curl: (6) Could not resolve host: pl.archive.ubuntu.com

Revelación

Eventualmente usé strace en curl y descubrí que era una conexión a nscd demonio

connect(4, sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket", 110) = 0

Solución

¡He reiniciado el servicio nscd (Name Service Cache Daemon) y ayudó a resolver este problema!

systemctl restart nscd.service

Aquí puedes ver las comentarios y valoraciones de los lectores

Si guardas algún titubeo o capacidad de enriquecer nuestro reseña puedes añadir un paráfrasis y con mucho placer lo ojearemos.

---

---

Utiliza Nuestro Buscador