Ik heb deze vreemde fout, CURL ERROR: Recv failure: Connection reset by peer
Dit is hoe het gebeurt, als ik geen verbinding heb gemaakt met de server en plotseling probeer verbinding te maken met de server via CURL in PHP, krijg ik de foutmelding. Wanneer ik het CURL-script opnieuw uitvoer, verdwijnt de fout en werkt vervolgens de hele tijd goed. Als ik de externe server ongeveer 30 minuten inactief laat of de externe server opnieuw opstart en opnieuw verbinding probeer te maken, krijg ik de fout opnieuw. Het lijkt dus alsof de verbinding inactief is en dan wordt de server plotseling wakker en werkt dan weer en slaapt dan weer.
Zo ziet mijn CURL-script eruit.
$url = Yii::app()->params['pdfUrl'];
$body = 'title='.urlencode($title).'&client_url='.Yii::app()->params['pdfClientURL'].'&client_id='.Yii::app()->params['pdfClientID'].'&content='.urlencode(htmlentities($content));
$c = curl_init ($url);
$body = array(
"client_url"=>Yii::app()->params['pdfClientURL'],
"client_id"=>Yii::app()->params['pdfClientID'],
"title"=>urlencode($title),
"content"=>urlencode($content)
);
foreach($body as $key=>$value) { $body_str .= $key.'='.$value.'&'; }
rtrim($body_str,'&');
curl_setopt ($c, CURLOPT_POST, true);
curl_setopt ($c, CURLOPT_POSTFIELDS, $body_str);
curl_setopt ($c, CURLOPT_RETURNTRANSFER, true);
curl_setopt ($c, CURLOPT_CONNECTTIMEOUT , 0);
curl_setopt ($c, CURLOPT_TIMEOUT , 20);
$pdf = curl_exec ($c);
$errorCode = curl_getinfo($c, CURLINFO_HTTP_CODE);
$curlInfo = curl_getinfo($c);
$curlError = curl_error($c);
curl_close ($c);
Ik heb totaal geen ideeën en oplossingen meer, help alsjeblieft, ik zal het op prijs stellen!!!
Als ik de uitvoer uitgebreid om te zien wat er gebeurt met
curl_setopt ($c, CURLOPT_VERBOSE, TRUE);
curl_setopt($c, CURLOPT_STDERR, $fp);
Ik krijg het volgende
* About to connect() to 196.41.139.168 port 80 (#0)
* Trying 196.x.x.x... * connected
* Connected to 196.x.x.x (196.x.x.x) port 80 (#0)
> POST /serve/?r=pdf/generatePdf HTTP/1.1
Host: 196.x.x.x
Accept: */*
Content-Length: 7115
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
* Recv failure: Connection reset by peer
* Closing connection #0
012 20:23:49 GMT
< Server: Apache/2.2.15 (CentOS)
< X-Powered-By: PHP/5.3.3
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
* Closing connection #0
Ik heb in de volgende teen toegevoegd om de standaardkoptekst te verwijderen en nog steeds geen geluk:
curl_setopt ($c, CURLOPT_HTTPHEADER, array( 'Expect:' ) );
> Accept: */* Content-Length: 8414 Content-Type:
> application/x-www-form-urlencoded
>
> * Recv failure: Connection reset by peer
> * Closing connection #0 r: Apache/2.2.15 (CentOS) < X-Powered-By: PHP/5.3.3 < Connection: close < Transfer-Encoding: chunked <
> Content-Type: text/html; charset=UTF-8 <
> * Closing connection #0
Antwoord 1, autoriteit 100%
Inleiding
De externe server heeft u een RST-pakket gestuurd, wat aangeeft dat de verbinding onmiddellijk wordt verbroken, in plaats van de gebruikelijke handdruk.
Mogelijke oorzaken
A. TCP/IP
Het kan een TCP/IP-probleem zijn dat je moet oplossen met je host of je besturingssysteem moet upgraden, meestal is de verbinding gesloten voordat de externe server klaar is met het downloaden van de inhoud, wat resulteert in Connection reset by peer.. …
B. Kannelbug
Merk op dat er enkele problemen zijn met het schalen van TCP-vensters op sommige Linux-kernels na v2.6.17. Zie de volgende bugrapporten voor meer informatie:
https://bugs.launchpad.net/ubuntu/+ source/linux-source-2.6.17/+bug/59331
https://bugs.launchpad.net/ubuntu/+ source/linux-source-2.6.20/+bug/89160
C. PHP & CURL-bug
U gebruikt PHP/5.3.3die ook enkele ernstige bugs heeft … ik zou u aanraden met een recentere versie van PHPen CURL
https://bugs.php.net/bug.php?id=52828
https://bugs.php.net/bug.php?id=52827
https://bugs.php.net/bug.php?id=52202
https://bugs.php.net/bug.php?id=50410
D. Maximale transmissie-eenheid
Een veelvoorkomende oorzaak van deze fout is dat de MTU-grootte (Maximum Transmission Unit) van pakketten die via uw netwerkverbinding worden verzonden, is gewijzigd van de standaardwaarde van 1500 bytes.
Als u VPNheeft geconfigureerd, moet dit hoogstwaarschijnlijk tijdens de configuratie worden gewijzigd
D. Firewall: iptables
Als je de weg niet weet, kunnen deze jongens ernstige problemen veroorzaken. Probeer toegang te krijgen tot de server waarmee je verbinding maakt om het volgende te controleren
- Je hebt toegang tot poort 80 op die server
Voorbeeld
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT`
- Het volgende staat op de laatste regel, niet eerder dan andere ACCEPTEREN
Voorbeeld
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-
Controleer op ALL DROP , REJECT en zorg ervoor dat ze je verbinding niet blokkeren
-
Tijdelijk alle verbindingen toestaan om te zien of het doordringt
Experiment
Probeer een andere server of externe server (zoveel betaalde cloudhosting online) en test hetzelfde script.. als het werkt, denk ik dat het zo goed als waar is… You need to update your system
Anderen code gerelateerd
A. SSL
Als Yii::app()->params['pdfUrl']een url is met httpszonder de juiste SSL-instelling, kan deze fout ook in de oude versie van krul
Oplossing: zorg ervoor dat OpenSSL is geïnstalleerd en ingeschakeld en voeg dit toe aan uw code
curl_setopt($c, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($c, CURLOPT_SSL_VERIFYHOST, false);
Ik hoop dat het helpt
Antwoord 2, autoriteit 16%
Normaal gesproken betekent deze fout dat er een verbinding tot stand is gebracht met een server, maar dat die verbinding is verbroken door de externe server. Dit kan te wijten zijn aan een trage server, een probleem met de externe server, een netwerkprobleem of (misschien) een soort beveiligingsfout met gegevens die naar de externe server worden verzonden, maar ik vind dat onwaarschijnlijk.
Normaal gesproken zal een netwerkfout zichzelf na een tijdje oplossen, maar het klinkt alsof u het al wat tijd hebt gegeven.
cURL heeft soms problemen met SSL en SSL-certificaten.
Ik denk dat je Apache en/of PHP is gecompileerd met een recente versie van de cURL- en cURL SSL-bibliotheken en ik denk niet dat OpenSSL op je webserver is geïnstalleerd.
Hoewel ik er niet zeker van kan zijn, geloof ik echter dat cURL in het verleden slecht is geweest met SSL-certificaten, terwijl Open SSL dat niet is.
Probeer in ieder geval Open SSL op de server te installeren en probeer het opnieuw. Dat zou je moeten helpen om van deze fout af te komen.
Antwoord 3, autoriteit 3%
Dus wat is de URL die Yii::app()->params['pdfUrl']geeft? Je zegt dat het https zou moeten zijn, maar het logboek laat zien dat het verbinding maakt op poort 80… waarop bijna geen server is ingesteld om https-verbindingen te accepteren. cURL is slim genoeg om te weten dat https op poort 443 moet staan… wat zou suggereren dat je URL iets raars bevat, zoals: https://196.41.139.168:80/serve/?r=pdf/generatePdf
Dat zal ervoor zorgen dat de verbinding wordt verbroken, terwijl de Apache aan de andere kant geen https-communicatie met je kan doen op die poort.
Je realiseert je dat je eerste $body-definitie wordt vervangen wanneer je $bodytwee regels later instelt op een array? {Waarschijnlijk gewoon een artefact van u die het probleem probeert op te lossen} U codeert ook niet de waarden client_urlen client_id(de eerste bevat mogelijk tekens die moeten worden ontsnapt!) Oh en je voegt toe aan $body_strzonder het eerst te initialiseren.
Uit uw uitgebreide uitvoer kunnen we zien dat cURL een content-lengthheader toevoegt, maar… is dit correct? Ik zie op internet wat opmerkingen dat dat nummer niet klopt (vooral bij oudere versies) … als dat aantal te klein was (bijvoorbeeld), zou je een verbindingsreset krijgen voordat alle gegevens zijn verzonden. U kunt de koptekst handmatig invoegen:
curl_setopt ($c, CURLOPT_HTTPHEADER,
array("Content-Length: ". strlen($body_str)));
O, en er is een handige functie http_build_querydie een array converteert van naam/waarde-paren in een URL-gecodeerde tekenreeks voor u.
Dit komt allemaal samen in de uiteindelijke code:
$post=http_build_query(array(
"client_url"=>Yii::app()->params['pdfClientURL'],
"client_id"=>Yii::app()->params['pdfClientID'],
"title"=>$title,
"content"=>$content));
//Open to URL
$c=curl_init(Yii::app()->params['pdfUrl']);
//Send post
curl_setopt ($c, CURLOPT_POST, true);
//Optional: [try with/without]
curl_setopt ($c, CURLOPT_HTTPHEADER, array("Content-Length: ".strlen($post)));
curl_setopt ($c, CURLOPT_POSTFIELDS, $post);
curl_setopt ($c, CURLOPT_RETURNTRANSFER, true);
curl_setopt ($c, CURLOPT_CONNECTTIMEOUT , 0);
curl_setopt ($c, CURLOPT_TIMEOUT , 20);
//Collect result
$pdf = curl_exec ($c);
$curlInfo = curl_getinfo($c);
curl_close($c);
Antwoord 4, autoriteit 3%
Ik kreeg te maken met dezelfde fout, maar op een andere manier.
Als je een pagina omkrult met een specifiek SSL-protocol.
curl --sslv3 https://example.com
Als –sslv3 niet wordt ondersteund door de doelserver, is de fout
krul: (35) TCP-verbinding opnieuw ingesteld door peer
Met het ondersteunde protocol is de fout verdwenen.
curl --tlsv1.2 https://example.com
Antwoord 5, autoriteit 2%
Dit is een firewallprobleem. Als u een VMware-toepassing gebruikt, zorg er dan voor dat de firewall op de antivirus is uitgeschakeld of verbindingen toestaat.
Als deze server zich in een beveiligd netwerk bevindt, bekijk dan de firewallregels van de server.
Bedankt
Ganesh PNS
Antwoord 6
We hadden hetzelfde probleem bij het maken van een websocket-verbinding met de Load Balancer.
Het probleem zit in LB, het accepteren van een http-verbinding op poort 80 en het doorsturen van het verzoek naar het knooppunt (tomcat-app op poort 8080).
We hebben dit gewijzigd om tcp (http is gewijzigd als ‘tcp’) verbinding op poort 80 te accepteren.
Dus het eerste handshake-verzoek wordt doorgestuurd naar Node en een websocket-verbinding wordt succesvol gemaakt op een willekeurige (voor zover ik weet, kan het fout zijn) poort.
het onderstaande commando is gebruikt om het websocket-handshake-proces te testen.
curl -v -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: localhost" -H "Origin: http://LB URL:80" http://LB URL
- URL opnieuw opgebouwd naar: http:LB URL/
- LB-URL proberen…
- TCP_NODELAY ingesteld
- Verbonden met LB URL (LB URL) poort 80 (#0)
GET / HTTP/1.1
Host: localhost
User-agent: krul/7.60.0
Accepteren: /
Verbinding: Upgrade
Upgrade: websocket
Oorsprong: http://LBURL:80 - Recv-fout: verbinding opnieuw ingesteld door peer
- Verbinding sluiten 0
curl: (56) Recv-fout: verbinding opnieuw ingesteld door peer
Antwoord 7
In mijn geval was er een probleem met de URL. Ik gebruik https://example.com– maar ze zorgen voor ‘www.’ – dus toen ik overstapte naar https://www.example.comwas alles in orde. De juiste header is verzonden ‘Host: www.example.com’.
Je kunt proberen een verzoek in Firefox brwoser te doen, het te bewaren en te kopiëren als cURL – zo heb ik het gevonden.