Curl ошибка 502

upstream prematurely closed connection

по результатам дискуссии выяснилось, что используется «upstream» в виде php-fpm, который в результате взаимодействия с libcurl «вылетает» при обращении к несуществующему доменному имени, что и приводит к выдаче программой nginx этого сообщения.

предлагаемый мною выход: проверять существование доменного имени до обращения к libcurl. например, с помощью функции checkdnsrr:

$ php -r 'if (checkdnsrr("ru.stackoverflow.com", $type="A")) { echo "da\n";} else {echo "net\n";}'
da
$ php -r 'if (checkdnsrr("rus.stackoverflow.com", $type="A")) { echo "da\n";} else {echo "net\n";}'
net

а извлекать доменное имя из url можно, например, с помощью функции parse_url:

$ php -r 'echo parse_url("http://rus.stackoverflow.com/blabla", $component=PHP_URL_HOST); echo "\n";'
rus.stackoverflow.com

по поводу неработоспособности ipv6:

можно ограничить libcurl работой только с ipv4 (см. документацию):

curl_setopt ($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);

Использую Yii2 httpclient

$client = new Client(['transport' => 'yii\httpclient\CurlTransport']);
        $response = $client->createRequest()
            ->setMethod('GET')
            ->setUrl($url)
            ->setHeaders([
                'Connection' => 'keep-alive',
                'sec-ch-ua' => '"Google Chrome";v="87", " Not;A Brand";v="99", "Chromium";v="87"',
                'Accept' => 'application/json, text/javascript, */*; q=0.01',
                'X-Requested-With' => 'XMLHttpRequest',
                'sec-ch-ua-mobile' => '?0',
                'User-Agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36',
                'Sec-Fetch-Site' => 'same-origin',
                'Sec-Fetch-Mode' => 'cors',
                'Sec-Fetch-Dest' => 'empty',
                'Accept-Language' => 'ru,en-US;q=0.9,en;q=0.8'
            ])
            ->setOptions([
                CURLOPT_PROXY => $this->proxy->getAddress(),
                CURLOPT_PROXYUSERPWD => $this->proxy->getLogin() . ":" . $this->proxy->getPassword(),
            ])
            ->send();

Вот код запроса. На локалке все работает: Openserver php 7.2
на серве phpfpm 7.2
но там не работает и выдаёт следующую ошибку:
Файл: vendor/yiisoft/yii2-httpclient/src/CurlTransport.php

Curl error: #56 - Received HTTP code 502 from proxy after CONNECT

В чем может быть проблема ?
Прокси мобильные от onlinesim.
Методы $this->proxy->getAddress(), $this->proxy->getLogin() и $this->proxy->getPassword() выдают валидные данные.

If you’re a developer or someone who works in tech, you’re likely already familiar with Postman. It’s a popular tool used by developers all around the world to test APIs, automate repetitive tasks, and much more. However, like any tool, it’s not perfect, and you may encounter some errors while using it. One of the most annoying errors is the 502 Bad Gateway error. In this guide, we’ll explain what the 502 Bad Gateway error is, why it occurs, and how to fix it.

What is the 502 Bad Gateway Error?

The 502 Bad Gateway error is an HTTP status code that indicates a server error. In other words, it indicates that there’s a problem with the server that’s attempting to fulfill the request. When you encounter the 502 error in Postman, it means that the request was sent, but the server returned an invalid or incomplete response.

Why Does the 502 Bad Gateway Error Occur?

There are several reasons why you may encounter the 502 Bad Gateway error in Postman. The most common causes include:

• Incorrect server configuration. This is when the server you’re communicating with is misconfigured. In most cases, this means that the server is unable to properly process your request or return a valid response.
• Overloaded servers. If the server is under too much load, it may be unable to handle your request. This can cause the server to time out or return an invalid response.
• Faulty network configuration. If there’s a problem with your network configuration, your request may not be able to reach its destination. This can cause the server to time out or return an invalid response.

How to Fix the 502 Bad Gateway Error

Fixing the 502 Bad Gateway error in Postman is usually straightforward. Here are a few things you can try:

• Check your API endpoint. Sometimes the error is caused by an incorrect API endpoint. Ensure that you’re using the correct endpoint, and try running the request again.
• Check your network configuration. Make sure that your network configuration is correct and that you’re not experiencing any connectivity issues.
• Refresh your browser. Try refreshing your browser and running the request again.
• Retry the request. If none of the above works, try re-sending the request. This may resolve the issue.

In most cases, one of these solutions will resolve the 502 Bad Gateway error. However, if you still encounter the error, you may need to contact the server administrator or seek additional help.

Conclusion

The 502 Bad Gateway error is a common error that occurs when using Postman. It can be caused by a variety of factors, including incorrect server configuration, overloaded servers, and faulty network configuration. However, resolving this error is often straightforward. By following the steps outlined in this guide, you can quickly fix the 502 error and get back to using Postman to test your APIs.

I am using NGINX as a reverse proxy and just put up a new service written in Go.

The service has two endpoints

GET /tracking/ping

POST /tracking/customer

In NGINX, I am using the following to proxy the request

location /v1/location/ {
    proxy_pass http://path-to-tracking-service:8181/;
}

When curl the two endpoints such as the following, I get different results.

The GET /tracking/ping endpoint

curl -X GET https://example.com/v1/location/tracking/ping
"Pong!"

The ‘POST /tracking/customer` endpoint

curl -H "Content-Type: application/json" -d '{"userId":"1234"}'  https://example.com/v1/location/tracking/customer
<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.9.12</center>
</body>

Not sure why this would happen. I am proxying other services I have and POST requests work perfectly fine.

Here is the nginx.conf

user nginx;
worker_processes 1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    proxy_connect_timeout       600;
proxy_send_timeout          600;
proxy_read_timeout          600;
send_timeout                600;

    #gzip  on;

    #include /etc/nginx/conf.d/*.conf;

    #server {
        #include /etc/nginx/sites-enabled/*;
    #}

    server {
        listen 80;
        server_name *.example.com;
        #return 301 https://$host$request_uri;
        include /etc/nginx/sites-enabled/*;
    }

    server {


    #listen 80;
    listen 443 ssl;
    server_name *.example.com;

    ssl_certificate           /etc/ssl/example.crt;
    ssl_certificate_key       /etc/ssl/example.key;

    #ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    include /etc/nginx/sites-enabled/*;
    }
}

I have separate files that are being linked to /sites-enabled that include my proxy_params declarations.

Two of them are the following

location /v1/location/ {
    proxy_pass http://example.com:8181/;
}

location /v1/ {
    proxy_pass http://example.com:8282/;
}

I could see their maybe being an issue with it getting confused by the /v1 on both the proxies, but it works for the GET endpoint.

EDIT

Some people have brought up the point that it may be panicking so I checked the docker logs for the go container and got the following

location-tracking-staging-1 | 2016-03-14T02:35:33.580963673Z 2016/03/14 02:35:33 http: panic serving 10.7.1.5:35613: no reachable servers
location-tracking-staging-1 | 2016-03-14T02:35:33.581005488Z goroutine 97 [running]:
location-tracking-staging-1 | 2016-03-14T02:35:33.581012905Z net/http.(*conn).serve.func1(0xc820057b00)
location-tracking-staging-1 | 2016-03-14T02:35:33.581017348Z    /usr/local/go/src/net/http/server.go:1389 +0xc1
location-tracking-staging-1 | 2016-03-14T02:35:33.581030498Z panic(0x81e620, 0xc82013c5e0)
location-tracking-staging-1 | 2016-03-14T02:35:33.581034545Z    /usr/local/go/src/runtime/panic.go:426 +0x4e9
location-tracking-staging-1 | 2016-03-14T02:35:33.581038792Z main.RepoCreateVendorLocation(0xc82011ecb8, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
location-tracking-staging-1 | 2016-03-14T02:35:33.581042502Z    /go/src/location-tracking/repo.go:19 +0x178
location-tracking-staging-1 | 2016-03-14T02:35:33.581047145Z main.VendorLocationCreate(0x7f8a4366d978, 0xc8200c2ea0, 0xc820119260)
location-tracking-staging-1 | 2016-03-14T02:35:33.581050747Z    /go/src/location-tracking/handlers.go:63 +0x47b
location-tracking-staging-1 | 2016-03-14T02:35:33.581054911Z net/http.HandlerFunc.ServeHTTP(0x9965b0, 0x7f8a4366d978, 0xc8200c2ea0, 0xc820119260)
location-tracking-staging-1 | 2016-03-14T02:35:33.581058786Z    /usr/local/go/src/net/http/server.go:1618 +0x3a
location-tracking-staging-1 | 2016-03-14T02:35:33.581062770Z github.com/gorilla/mux.(*Router).ServeHTTP(0xc820010640, 0x7f8a4366d978, 0xc8200c2ea0, 0xc820119260)
location-tracking-staging-1 | 2016-03-14T02:35:33.581066604Z    /go/src/github.com/gorilla/mux/mux.go:103 +0x270
location-tracking-staging-1 | 2016-03-14T02:35:33.581070176Z net/http.serverHandler.ServeHTTP(0xc820056300, 0x7f8a4366d978, 0xc8200c2ea0, 0xc820119260)
location-tracking-staging-1 | 2016-03-14T02:35:33.581073992Z    /usr/local/go/src/net/http/server.go:2081 +0x19e
location-tracking-staging-1 | 2016-03-14T02:35:33.581077629Z net/http.(*conn).serve(0xc820057b00)
location-tracking-staging-1 | 2016-03-14T02:35:33.581081221Z    /usr/local/go/src/net/http/server.go:1472 +0xf2e
location-tracking-staging-1 | 2016-03-14T02:35:33.581084811Z created by net/http.(*Server).Serve
location-tracking-staging-1 | 2016-03-14T02:35:33.581088336Z    /usr/local/go/src/net/http/server.go:2137 +0x44e