NGGINX stroomopwaarts voortijdig gesloten verbinding tijdens het lezen van de responskop van stroomopwaarts, voor grote verzoeken

Ik gebruik NGINX- en NODE-server om update-verzoeken te dienen. Ik krijg een gateway-time-out wanneer ik een update over grote gegevens aanvraag. Ik zag deze fout van de NGINX-foutlogboeken:

2016/04/07 00:46:04 [FOUT] 28599 # 0: * 1 Upstream vroegtijdig gesloten
verbinding tijdens het lezen van respons header van upstream, client:
10.0.2.77, server: gis.oneconcern.com, aanvraag: “Ontvang / update_mbtiles / ATLAS19891018000415 HTTP / 1.1”, Upstream:
“http://127.0.0.1:7777/Update_mbtiles/atlas19891018000415”, Host:
“GIS.ONeconcern.com”

Ik googled voor de fout en probeerde alles wat ik kon, maar ik krijg nog steeds de fout.

Mijn NGINX CONF heeft deze proxy-instellingen:

   ##
    # Proxy settings
    ##
    proxy_connect_timeout 1000;
    proxy_send_timeout 1000;
    proxy_read_timeout 1000;
    send_timeout 1000;

Dit is hoe mijn server is geconfigureerd

server {
listen 80;
server_name gis.oneconcern.com;
access_log /home/ubuntu/Tilelive-Server/logs/nginx_access.log;
error_log /home/ubuntu/Tilelive-Server/logs/nginx_error.log;
large_client_header_buffers 8 32k;
location / {
    proxy_pass http://127.0.0.1:7777;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $http_host;
    proxy_cache_bypass $http_upgrade;
}
location /faults {
    proxy_pass http://127.0.0.1:8888;
    proxy_http_version 1.1;
    proxy_buffers 8 64k;
    proxy_buffer_size 128k;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
}

}

Ik gebruik een nodejs-backend om de verzoeken op een aws-server te verwerken. De gateway-fout wordt alleen weergegeven als de update lang duurt (ongeveer 3-4 minuten). Ik krijg geen foutmelding voor kleinere updates. Alle hulp wordt zeer op prijs gesteld.

Node js-code :

app.get("/update_mbtiles/:earthquake", function(req, res){
var earthquake = req.params.earthquake
var command = spawn(__dirname + '/update_mbtiles.sh', [ earthquake, pg_details ]);
//var output  = [];
command.stdout.on('data', function(chunk) {
//    logger.info(chunk.toString());
//     output.push(chunk.toString());
});
command.stderr.on('data', function(chunk) {
  //  logger.error(chunk.toString());
 //   output.push(chunk.toString());
});
command.on('close', function(code) {
    if (code === 0) {
        logger.info("updating mbtiles successful for " + earthquake);
        tilelive_reload_and_switch_source(earthquake);
        res.send("Completed updating!");
    }
    else {
        logger.error("Error occured while updating " + earthquake);
        res.status(500);
        res.send("Error occured while updating " + earthquake);
    }
});
});
function tilelive_reload_and_switch_source(earthquake_unique_id) {
tilelive.load('mbtiles:///'+__dirname+'/mbtiles/tipp_out_'+ earthquake_unique_id + '.mbtiles', function(err, source) {
    if (err) {
        logger.error(err.message);
        throw err;
    }
    sources.set(earthquake_unique_id, source); 
    logger.info('Updated source! New tiles!');
});
}

Bedankt.

Antwoord 1, autoriteit 100%

Ik denk dat die fout van Nginx aangeeft dat de verbinding is gesloten door je nodejs-server (d.w.z. “upstream”). Hoe is nodejs geconfigureerd?

Antwoord 2, autoriteit 93%

Ik heb dit opgelost door een hogere time-outwaarde in te stellen voor de proxy:

location / {
    proxy_read_timeout 300s;
    proxy_connect_timeout 75s;
    proxy_pass http://localhost:3000;
}

Documentatie: https://nginx.org/en/docs/http/ngx_http_proxy_module. html

Antwoord 3, autoriteit 43%

Ik had al een tijdje dezelfde fout, en hier is wat het voor mij heeft opgelost.

Ik heb eenvoudig in dienst verklaard dat ik het volgende gebruik:

Description= Your node service description
After=network.target
[Service]
Type=forking
PIDFile=/tmp/node_pid_name.pid
Restart=on-failure
KillSignal=SIGQUIT
WorkingDirectory=/path/to/node/app/root/directory
ExecStart=/path/to/node /path/to/server.js
[Install]
WantedBy=multi-user.target

Wat hier uw aandacht zou moeten trekken, is “After=network.target”.
Ik heb dagen en dagen besteed aan het zoeken naar oplossingen aan de kant van nginx, terwijl het probleem precies dat was.
Om zeker te zijn, stop met het uitvoeren van de node-service die je hebt, start de opdracht ExecStart direct en probeer de bug te reproduceren. Als het niet verschijnt, betekent dit alleen dat uw service een probleem heeft. Zo vond ik tenminste mijn antwoord.

Voor alle anderen, veel succes!

Antwoord 4, autoriteit 21%

Ik denk niet dat dit jouw zaak is, maar ik zal het posten als het iemand helpt. Ik had dezelfde kwestie en het probleem was dat knooppunt helemaal niet reageerde (ik had een aandoening dat wanneer het niets is gedaan – dus geen reactie) – dus als het verhogen van al je time-outs het niet oplost Alle scenario’s krijgen een reactie.

Antwoord 5, Autoriteit 21%

U kunt de time-out in knooppunt zoals SO vergroten.

app.post('/slow/request', function(req, res) {
    req.connection.setTimeout(100000); //100 seconds
    ...
}

Antwoord 6, Autoriteit 14%

Ik liep dit probleem ook in en vond deze post. Uiteindelijk heeft geen van deze antwoorden mijn probleem opgelost, in plaats daarvan moest ik in een herschrijfregel plaatsen om de location /rtte strippen als de backend My Developers maakte geen extra paden:

┌─(william@wkstn18)──(Thu, 05 Nov 20)─┐
└─(~)──(16:13)─>wscat -c ws://WebsocketServerHostname/rt
error: Unexpected server response: 502

Testen met WSCAT gaf herhaaldelijk een reactie van 502. NGINX-foutlogboeken verschaft dezelfde upstream-fout zoals hierboven, maar kennisgeving De upstream-tekenreeks toont het ontvangen verzoek om toegang te krijgen tot LocalHost: 12775 / RT en niet localhost: 12775:

2020/11/05 22:13:32 [error] 10175#10175: *7 upstream prematurely closed
 connection while reading response header from upstream, client: WANIP,
 server: WebsocketServerHostname, request: "GET /rt/socket.io/?transport=websocket
 HTTP/1.1", upstream: "http://127.0.0.1:12775/rt/socket.io/?transport=websocket",
 host: "WebsocketServerHostname"

Omdat de ontwikkelaars hun websocket niet hadden gecodeerd (luisteren op 12775) om /rt/socket.io te verwachten, maar in plaats daarvan alleen /socket.io/ (OPMERKING: /socket.io/ lijkt slechts een manier te zijn om websocket-transport te specificeren hierbesproken). Daarom, in plaats van hen te vragen hun socketcode te herschrijven, heb ik gewoon een herschrijfregel ingevoerd om WebsocketServerHostname/rt te vertalen naar WebsocketServerHostname:12775zoals hieronder:

upstream websocket-rt {
        ip_hash;
        server 127.0.0.1:12775;
}
server {
        listen 80;
        server_name     WebsocketServerHostname;
        location /rt {
                proxy_http_version 1.1;
                #rewrite /rt/ out of all requests and proxy_pass to 12775
                rewrite /rt/(.*) /$1  break;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_pass http://websocket-rt;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
        }
}

Antwoord 7

Ik heb hetzelfde probleem en geen van de hier beschreven oplossingen werkte voor mij …
Allereerst had ik een fout 413 Entity te groot, dus ik heb mijn nginx.conf als volgt bijgewerkt:

http {
        # Increase request size
        client_max_body_size 10m;
        ##
        # Basic Settings
        ##
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;
        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;
        include /etc/nginx/mime.types;
        default_type application/octet-stream;
        ##
        # SSL Settings
        ##
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;
        ##
        # Logging Settings
        ##
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
        ##
        # Gzip Settings
        ##
        gzip on;
        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
        ##
        # Virtual Host Configs
        ##
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
        ##
        # Proxy settings
        ##
        proxy_connect_timeout 1000;
        proxy_send_timeout 1000;
        proxy_read_timeout 1000;
        send_timeout 1000;
}

Dus ik heb alleen het http-gedeelte geüpdatet en nu kom ik de fout 502 Bad Gateway tegen en wanneer ik /var/log/nginx/error.log weergeef, kreeg ik de beroemde “upstream voortijdig gesloten verbinding tijdens het lezen van de responsheader van de upstream”

Wat voor mij echt mysterieus is, is dat het verzoek werkt wanneer ik het met virtualenv op mijn server uitvoer en het verzoek stuur naar de: IP:8000/nameOfTheRequest

Bedankt voor het lezen

Antwoord 8

Ik kreeg dezelfde fout, dit is hoe ik het heb opgelost:

• Gedownloade logboeken van AWS.
• Gecontroleerde Nginx-logboeken, geen aanvullende details zoals hierboven.
• Gecontroleerde node.js-logboeken, AccessDenied AWS SDK-machtigingenfout.
• De S3-bucket gecontroleerd waaruit AWS probeerde te lezen.
• Extra bucket met leesrechten toegevoegd om de serverrol te corrigeren.

Hoewel ik grote bestanden aan het verwerken was, waren er geen andere fouten of instellingen die ik moest wijzigen nadat ik de ontbrekende S3-toegang had gecorrigeerd.

Antwoord 9

Probleem

De upstream-server heeft een time-out en ik weet niet wat er gebeurt.

Waar moet u eerst kijken voordat u de lees- of schrijftime-out verhoogt als uw server verbinding maakt met een database

De server maakt verbinding met een database en die verbinding werkt prima en binnen een redelijke reactietijd, en het is niet degene die deze vertraging in de reactietijd van de server veroorzaakt.

zorg ervoor dat de verbindingsstatus geen trapsgewijze storing veroorzaakt in uw upstream

Vervolgens kunt u naar de time-outconfiguraties voor lezen en schrijven van de server en proxy kijken.

Antwoord 10

Ik stuitte op *145660 upstream prematurely closed connection while reading upstreamNginx-foutlogboekvermelding bij het downloaden van een 2GB-bestand van de server waarvoor Nginx een proxy was. Het bericht geeft aan dat de “upstream” verbinding heeft gesloten, maar in feite was deze gerelateerd aan proxy_max_temp_file_sizeinstelling:

Syntaxis: grootte proxy_max_temp_file_size;
Standaard: proxy_max_temp_file_size 1024m;
Context: http, server, locatie

Wanneer het bufferen van antwoorden van de proxyserver is ingeschakeld en het hele antwoord niet past in de buffers die zijn ingesteld door de richtlijnen proxy_buffer_size en proxy_buffers, kan een deel van het antwoord worden opgeslagen in een tijdelijk bestand. Deze richtlijn stelt de maximale grootte van het tijdelijke bestand in. De grootte van de gegevens die tegelijk naar het tijdelijke bestand worden geschreven, wordt ingesteld door de instructie proxy_temp_file_write_size.

De nulwaarde schakelt het bufferen van reacties op tijdelijke bestanden uit.

Deze beperking is niet van toepassing op antwoorden die in de cache worden opgeslagen of op schijf worden opgeslagen.

De symptomen:

• download werd gedwongen gestopt bij ongeveer 1 GB,
• Nginx beweerde dat de upstream gesloten verbinding, maar zonder proxyserver de volledige inhoud retourneerde.

De oplossing:

• verhoogde proxy_max_temp_file_sizevoor proxy-locatie tot 4096men het begon met het verzenden van volledige inhoud.