Что значит curl error 6

Trying to find a solution for ‘WordPress cURL Error 6: Could not resolve host’? Here’s how we fix it.

The cURL error 6 indicates that the cURL can’t resolve the hostname and it happens whenever there is a problem with the DNS server.

At Bobcares, we often receive requests to fix cURL errors as a part of our Server Management Services.

Today, let’s explore more on this error and see how our Support Engineers fix it.

What is cURL error 6?

cURL error 6 mainly occurs when the given remote host does not resolve properly. Also, it is related to the DNS, and we fix this error by resolving the DNS.

Now, let’s discuss the exact scenario of the error. Recently, one of our WordPress customers approached us with the below error message.

He confirmed that he started to receive this error after updating a plugin on the website.

How we fix the WordPress cURL Error 6: Could not resolve host?

On checking, our Support Engineers found that the error was occurring due to the WordPress plugin.We follow the below steps to fix the error.

1. First, we log in via SSH and edit /etc/resolv.conf.

vi /etc/resolv.conf

2. Next, we add Google public name servers and comment on the other nameservers.

nameserver 8.8.8.8
nameserver 8.8.4.4
#nameserver 1xx.1xx.1xx.x
#nameserver 1xx.1xx.1xx.x

3. Then after making the changes, we restart Apache or Nginx.

service apache2 restart

This fixes the error.

But sometimes the changes we made to /etc/resolv.conf file will be erased on reboot or restart. So we make some permanent changes in resolv.conf file.

sudo apt-get install resolvconf

Then we open the file to add the nameservers.

vi /etc/resolvconf/resolv.conf.d/base

After that, we add the nameservers on the file.

nameserver 8.8.8.8
nameserver 8.8.4.4

Finally, we save the file. By adding the Google name serves will fix the WordPress cURL Error 6.

[Need assistance in fixing cURL errors? – Our Experts are available 24/7.]

Conclusion

In short, the WordPress cURL Error 6: Could not resolve host error occurs during the WordPress plugin updates and it is related to DNS. Today, we saw how our Support Engineers fix this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

As Linux users continue to skillfully nurture and grow their user experience, they soon realize that they become more performant and productive while in the Linux command-line environment.

The Linux OS environment exposes its users to terminal-based tools like Curl for a non-interactive download and upload of targeted network/internet-based files, which is similar to the Wget utility and both share some similarities in their implementation and functionalities.

The primary role of the Curl utility as highlighted on its manual page is to transfer a targeted URL.

$ man curl 

It supports numerous protocols with the common ones being FTP, FTPS, HTTP, HTTPS, SCP, SFTP, SMTP, and SMTP.

The Curl command syntax is as follows:

$ curl [options / URLs]

We can show its implementation by using it with a random URL.

$ curl https://google.com -o linuxshelltips.txt

In the above command, Curl’s findings from accessing the highlighted URL are saved in the succeeding text file.

curl: (6) could not resolve host Error

Mostly, such an error occurs when there is an issue with a Linux server’s DNS resolver. A Linux administrator will categorize/define this challenge as a server management service issue.

This error is likely to take several forms when the curl command is executed from the Linux terminal and the most popular ones include:

• curl: (6) could not resolve host: domain_name.extension; Name or service not known
• curl: (6) could not resolve host: domain_name.extension e.g. linuxshelltips.com
• curl: (6) could not resolve host: application

Now that we have highlighted the primary reason that might be behind the stated curl command error during its execution on a Linux terminal, it’s time to fix the problem.

Solution 1: Missing Working DNS Nameserver

A nameserver is basically a bridge between a working/purchased domain name and the IP address of a server. When you purchase or subscribe to a domain name, and before you use/link this domain name to your remote Linux server, you need to configure a DNS nameserver. A DNS nameserver enables a user to use a domain name to access a remote server instead of using its IP address.

On your Linux server/machine, the file /etc/resolv.conf is responsible for the DNS nameserver entries auto-generated by NetworkManager.

$ sudo nano /etc/resolv.conf

This file can hold more than one DNS nameserver entry. As you might have noted, the syntax for adding a DNS nameserver entry in this file should resemble the following:

nameserver   IP.ADDRESS

For instance, if you were to add Google public nameservers to this file, it would look like the following:

nameserver   192.168.100.1
nameserver   8.8.8.8
nameserver   8.8.4.4

If you are using a private DNS nameserver, add it to the /etc/resolv.conf file. Update or reboot the system if possible and the host should start resolving.

Solution 2: Curl Syntax Errors

Make sure the curl command execution adheres to its correct syntax usage. A syntax error can arise from something as simple as the misuse of an escape sequence (/) or an illegal spacing on the URL.

The curl: (6) could not resolve host error in Linux primarily relates to wrongful/missing DNS nameserver setup or a random syntax error that can be scanned and fixed.

1. It’s interesting that it’s only curl that’s giving trouble, and only with Guzzle. I’m not convinced this is a Valet issue.
   You could maybe enable Guzzle’s debug mode, to get more information back:
   http://docs.guzzlephp.org/en/latest/request-options.html#debug

You could also install an alternate Client to override the default of using CURL: http://docs.guzzlephp.org/en/latest/faq.html#does-guzzle-require-curl

1. I wouldn’t have expected a simple yarn update to do anything that’s interfering, unless it’s gone and installed some package that set some new ENV vars that CURL uses, or something that provides DNS services and now is clashing with dnsmasq or osx core. And if it does then that raises other concerns, beyond the scope of Valet.
   But, one way to rule it out is to delete everything yarn installed, and then remove the node_modules dir, and reboot. And if it’s from «global» tools that yarn installed, clean those up too. Maybe not «ideal», but useful as a troubleshooting step nonetheless.

2. Given that you said other services are able to reach site.test it means dnsmasq «is» running, so the following troubleshooting for dnsmasq is probably pointless, but I’ll leave it here for reference anyway.

DNSMASQ troubleshooting

Top 3 troubleshooting steps I’ve taken with dnsmasq issues:

• use dig to find out what’s happening with lookups
• enable dnsmasq logging to get it to report any startup problems
• inspect OSX config

dig

dig site.test
This should come back with something like the following. Note the «A» record pointing to 127.0.0.1, and the SERVER: 127.0.0.1 in the following, and what’s different in yours.

; <<>> DiG 9.10.6 <<>> site.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58405
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;site.test.			IN	A

;; ANSWER SECTION:
site.test.		0	IN	A	127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 01 10:26:39 EST 2019
;; MSG SIZE  rcvd: 54

logging

Enabling logging in dnsmasq:
One place to do this is in ~/.config/valet/dnsmasq.conf
It should already have 2 lines in it for your configured TLD.
Add the following lines, adjusting for your actual username:

# Logging
log-facility=/Users/MY_USERNAME/Downloads/dnsmasq.log
log-queries

Then sudo brew services stop dnsmasq && sudo brew services start dnsmasq && brew services list
What’s the output? Does it show dnsmasq running as root?
Then look in your ~/Downloads/dnsmasq.log file for any messages, particularly things pointing out problems.
(Once you’ve resolved your dnsmasq issues, remove those logging entries, since it’ll just waste disk space.)

OSX networking

• System Preferences -> Network -> Advanced -> DNS
  For dnsmasq to be the first lookup source, the first DNS listing should be 127.0.0.1

Буквально пару дней назад переносили сайт на WordPress на обновленный сервер, и столкнулись с проблемой установки обновлений и новых плагинов. Если поискать в интернете, видно, что люди часто сталкиваются с такой ошибкой и предлагается всего 2 варианта решения:

1. Подождите, может, само рассосется
2. Обратитесь к системному администратору

Ждать — не вариант. Если вы используете виртуальный хостинг одного из хостеров, то техподдержка должна решить эту проблему достаточно быстро. А если вы арендовали VPS и сами себе администратор, то информация ниже поможет вам решить проблему.

Как проявляется ошибка

Ошибка возникает при попытке установить обновление WordPress, обновить темы оформления или установить новый плагин. При этом появляется сообщение «Warning: Произошла непредвиденная ошибка. Возможно, что-то не так с сайтом WordPress.org или с настройками вашего сервера. Если проблема не решится, обратитесь на форумы поддержки. (Не удалось установить защищённое соединение с WordPress.org. Пожалуйста, свяжитесь с администратором сервера)».

В логах сервера фигурируют следующие файлы, в которых возникает ошибка:
/wp-admin/includes/plugin-install.php
/wp-admin/includes/translation-install.php
/wp-admin/includes/update.php
/wp-includes/update.php

Если у вас установлен плагин Health Check & Troubleshooting (кстати, настоятельно рекомендую его установить), то в отчете можно увидеть ошибки вида
cURL error 6: Could not resolve host: api.wordpress.org

Очевидно, что проблема в библиотеке cURL, либо настройках сервера.

Как решить проблему

Нам понадобится доступ к серверу по протоколу SSH и права администратора для внесения изменений в настройки и установки ряда библиотек.

1. Проверяем настройки в файле php.ini
Обычно этот файл находится в папке /etc/php.ini или /etc/php/<версия php>/apache2/php.ini. Убедитесь, что эти две настройки включены:
allow_url_fopen = On
allow_url_include = On

2. Проверяем установку необходимых библиотек с помощью phpinfo()
Создайте на своем сервере файл pi.php в корне сайта со следующим содержимым:
<?php
phpinfo();
Откройте файл в браузере http://<адрес сервера>/pi.php и проверьте, что следующие библиотеки установлены в Enabled
OpenSSL 
Socket

3. Проверяем файл resolv.conf
Файл можно найти по адресу /etc/resolv.conf — воспользуйтесь привычным текстовым редактором. Удалите из файла все комментарии, укажите используемые DNS-сервера (рекомендую Google, но вы можете выбрать те, которые нравятся):
nameserver 8.8.8.8
nameserver 8.8.4.4
Сохраните изменения и закройте редактор. Убедитесь, что файл доступен для всех пользователей:
chmod a+r /etc/resolv.conf

4. Если вы используете высокоэффективную связку nginx + php-fpm

Для начала проверяем конфигурацию php-fpm для вашего сайта. Ее можно найти в /etc/php-fpm.d/<имя сайта>.conf. Откройте файл и найдите строку
chroot = <путь к песочнице>
Если строка присутствует и не закомментирована, значит php-fpm работает в режиме chroot, и вам потребуется скопировать часть файлов системы в chroot-окружение, т.к. у php-fpm нет к ним доступа. Для этого переходим в папку, указанную в chroot и выполняем следующие команды:
mkdir etc
mkdir lib64
mkdir usr
mkdir usr/share
cp -p /etc/hosts etc/
cp -p /etc/localtime etc/
cp -p /etc/resolv.conf etc/
cp -p /lib64/libss_dns* lib64/
cp -Rp /usr/share/zoneinfo usr/share/

После выполнения указанных действий перезапускаем php-fpm, и проблема решена.
systemctl restart php-fpm

Если вам требуется сопровождение VPS/VDS-сервера или помощь с настройкой, обратитесь к нам, мы занимаемся настройкой и сопровождением серверов с 2013 года. Порекомендуем хостера, подберем конфигурацию и поможем запустить ваш проект.

I am trying to consume a web service. I have my dev environment(laptop) which is on windows, and also a test environment(server) which is on Fedora. Both share the same internet connection and also the same source code for the application I am testing.

The current problem

• When I am doing a test using my dev environment, I get a valid response
• When I am doing a test using the test environment, I am getting Curl Error No 6 (could not resolve host)
• I can view the WSDL on the test environment using the curl command in the terminal
• I can view the WSDL in the browser when I browse it.
• I have tried the webservice using SOAPUI on my dev environment and I managed to get a valid response as well.
• unfortunately, I cannot find SOAPUI for fedora so I cannot test it on the test environment using SOAPUI.
• I am able to consume other partner’s webservice using test environment.

Anyone can suggest me what is going on and how to fix it? Whether it is a network problem or the source code?

Below is my source code:

    function execute_curl($variables)   //removed variables because its too long
    {
        $this->CI->load->model('mws_transmit_model');

        $ch = curl_init();

        curl_setopt($ch, CURLOPT_URL, $URL);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: text/xml','SOAPAction:"'.$http_header.'"'));
        curl_setopt($ch, CURLOPT_HEADER, 0);
        curl_setopt($ch, CURLOPT_POST, TRUE);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $string);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_PORT, 443);

        if(isset($ssl_version)):
        {
            curl_setopt($ch, CURLOPT_SSLVERSION, $ssl_version);
        }
        endif;

        if(isset($ca_info)):
        {
            //curl_setopt($ch, CURLOPT_CAINFO, $ca_info);
        }
        endif;

        if(isset($ssl_cert)):
        {
            //curl_setopt($ch, CURLOPT_SSLCERT, $ssl_cert);
        }
        endif;

        if(isset($ssl_cert_pass)):
        {
            //curl_setopt($ch, CURLOPT_SSLCERTPASSWD, $ssl_cert_pass);
        }
        endif;

        if(isset($time_out)):
        {
            if($time_out !== "0"):
            {
                curl_setopt($ch, CURLOPT_TIMEOUT, $time_out);
            }
            endif;

        }
        endif;

        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);

        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

        $ch_result = curl_exec($ch);

        if(curl_errno($ch) == "0"):
        {
            //RETURN SUCCESSFUL CONSUMPTION OF WEB SERVICE
        }
        else:
        {
            //RETURN ERROR
        }
        endif;
    }

I am trying to consume a web service. I have my dev environment(laptop) which is on windows, and also a test environment(server) which is on Fedora. Both share the same internet connection and also the same source code for the application I am testing.

The current problem

• When I am doing a test using my dev environment, I get a valid response
• When I am doing a test using the test environment, I am getting Curl Error No 6 (could not resolve host)
• I can view the WSDL on the test environment using the curl command in the terminal
• I can view the WSDL in the browser when I browse it.
• I have tried the webservice using SOAPUI on my dev environment and I managed to get a valid response as well.
• unfortunately, I cannot find SOAPUI for fedora so I cannot test it on the test environment using SOAPUI.
• I am able to consume other partner’s webservice using test environment.

Anyone can suggest me what is going on and how to fix it? Whether it is a network problem or the source code?

Below is my source code:

    function execute_curl($variables)   //removed variables because its too long
    {
        $this->CI->load->model('mws_transmit_model');

        $ch = curl_init();

        curl_setopt($ch, CURLOPT_URL, $URL);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: text/xml','SOAPAction:"'.$http_header.'"'));
        curl_setopt($ch, CURLOPT_HEADER, 0);
        curl_setopt($ch, CURLOPT_POST, TRUE);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $string);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_PORT, 443);

        if(isset($ssl_version)):
        {
            curl_setopt($ch, CURLOPT_SSLVERSION, $ssl_version);
        }
        endif;

        if(isset($ca_info)):
        {
            //curl_setopt($ch, CURLOPT_CAINFO, $ca_info);
        }
        endif;

        if(isset($ssl_cert)):
        {
            //curl_setopt($ch, CURLOPT_SSLCERT, $ssl_cert);
        }
        endif;

        if(isset($ssl_cert_pass)):
        {
            //curl_setopt($ch, CURLOPT_SSLCERTPASSWD, $ssl_cert_pass);
        }
        endif;

        if(isset($time_out)):
        {
            if($time_out !== "0"):
            {
                curl_setopt($ch, CURLOPT_TIMEOUT, $time_out);
            }
            endif;

        }
        endif;

        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);

        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

        $ch_result = curl_exec($ch);

        if(curl_errno($ch) == "0"):
        {
            //RETURN SUCCESSFUL CONSUMPTION OF WEB SERVICE
        }
        else:
        {
            //RETURN ERROR
        }
        endif;
    }