ERR_CONNECTION_REFUSED: årsager og rettelse

Hvad fejlen betyder

Browseren fandt serverens adresse, sendte en forbindelsesanmodning til port 443 (eller 80), og serveren svarede “nej”: en TCP-reset, som operativsystemet sender, når intet program lytter på den port. Chrome viser ERR_CONNECTION_REFUSED (“Webstedet kan ikke nås”), Firefox “Kan ikke oprette forbindelse”, Safari “Safari kan ikke oprette forbindelse til serveren”.

Det er noget andet end en timeout (intet svarer overhovedet, som regel en firewall, der dropper pakker, eller en server, der er slukket) og end DNS_PROBE_FINISHED_NXDOMAIN (navnet kan ikke slås op). En afvist forbindelse betyder: maskinen er oppe og kan nås, men webserveren på den kører ikke, lytter på en anden port eller adresse eller er blokeret af en firewall, der afviser frem for at droppe.

Almindelige årsager

1. Webserveren er stoppet. nginx eller Apache gik ned, kunne ikke starte efter en konfigurationsændring eller blev stoppet af en opdatering. Langt den hyppigste årsag.
2. Webserveren lytter på den forkerte adresse eller port. Efter en ændring af listen-direktiverne binder nginx kun til 127.0.0.1 eller kun til IPv4, mens DNS-recorden peger på en IPv6-adresse.
3. En firewall afviser porten. ufw, firewalld eller en cloud-sikkerhedsgruppe med en reject-regel for 80/443, ofte efter at nogen “hærdede” serveren.
4. En ny server uden webserver. DNS-recorden peger allerede på den nye IP, men nginx er endnu ikke installeret eller startet.
5. HTTPS er ikke sat op. Port 80 virker, port 443 har ingen lytter, og browseren (eller en HSTS-post) insisterer på HTTPS.
6. Lokale årsager hos den besøgende. En proxy-indstilling, der peger på en død proxy, en VPN, antivirusprogrammets “webskjold”, en post i hosts-filen eller en browserudvidelse.

Hvis du er besøgende

1. Prøv hjemmesiden i et privat vindue og med en anden browser, hvilket udelukker udvidelser og cache.
2. Tjek proxy-indstillinger: Windows “Proxyindstillinger”, macOS Netværk > Avanceret > Proxyer. Slå en manuel proxy fra, som du ikke bruger.
3. Slå VPN og antivirusprogrammets webbeskyttelse fra et øjeblik.
4. Ryd DNS (ipconfig /flushdns, sudo dscacheutil -flushcache), hvis din cache rummer en gammel adresse på en hjemmeside, der er flyttet.
5. Prøv én gang http:// i stedet for https://; virker det, er hjemmesidens HTTPS ødelagt, og ejeren må rette det.

Hvis det er din hjemmeside: tjek først

Kør tjekket af, om hjemmesiden er nede. “Connection refused” udefra bekræfter, at selve serveren afviser. Log så ind via SSH (at SSH virker, mens hjemmesiden afviser, er i sig selv et stærkt fingerpeg: serveren er oppe, webserveren er ikke).

# kører webserveren?
systemctl status nginx
systemctl status apache2

# hvad lytter på 80 og 443?
sudo ss -tlnp | grep -E ':80 |:443 '

# firewallregler
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset | grep -E 'dport (80|443)'

Viser ss intet på 443, er webserveren nede eller ikke konfigureret til den. Viser den 127.0.0.1:443 i stedet for 0.0.0.0:443 eller *:443, lytter den kun lokalt.

Rettelser på din egen server

1. Start webserveren, og læs hvorfor den stoppede

sudo systemctl start nginx
systemctl status nginx
sudo journalctl -u nginx -n 50

Kan den ikke starte, er årsagerne næsten altid en af disse:

• nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use): et andet program holder porten (Apache og nginx begge installeret, eller en forældet proces). sudo ss -tlnp | grep :80 navngiver det; stop det, du ikke vil have.
• [emerg] unknown directive eller unexpected "}": en syntaksfejl i en konfigurationsfil. sudo nginx -t udskriver filen og linjen.
• cannot load certificate: en certifikatfil blev slettet eller fornyet til en anden sti. Sammenlign linjerne med ssl_certificate med det, der ligger på disken.
• Too many open files eller en fuld disk: df -h, df -i.

Apache: sudo apachectl configtest, derefter sudo journalctl -u apache2 -n 50. De samme kategorier gælder; AH00558 (could not determine server name) er kun en advarsel, ikke årsagen.

Test altid, før du genindlæser, og genindlæs frem for at genstarte, når det er muligt:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Lyt på den rigtige adresse

I nginx’ server-blok skal begge disse bruges til IPv4 og IPv6:

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

Har DNS en AAAA-record, men serveren lytter ikke på IPv6 (eller har ingen IPv6-forbindelse), får besøgende på IPv6 en afvist forbindelse, mens alle andre er fine. Få den enten til at lytte, eller fjern AAAA-recorden.

3. Åbn firewallen

# ufw (Debian/Ubuntu)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld (RHEL-familien)
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

På en cloudserver skal du også tjekke udbyderens sikkerhedsgruppe eller netværksfirewall i kontrolpanelet; en regel dér er usynlig indefra serveren.

4. Sæt HTTPS op, hvis kun port 80 svarer

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot tilføjer 443-server-blokken og omdirigeringen. Tjek derefter med SSL-checkeren, at kæden er komplet.

5. Efter en serverflytning

Sørg for, at webserveren på den nye maskine er installeret, konfigureret til domænet og startet, før du ændrer DNS. Har du allerede ændret det: installér og start den nu, eller peg recorden tilbage på den gamle server, til den nye er klar.

Når det er din hostingudbyders problem

Ved delt hosting betyder en afvist forbindelse, at hostingudbyderens webserver er nede for din node, eller at de har flyttet dig til en ny IP uden at opdatere DNS. Send:

Hej, min hjemmeside example.com har returneret “connection refused” på port 80 og 443 siden ca. kl. 20:15 UTC. Domænet peger på 203.0.113.10. Jeg har ikke ændret noget på min konto. Er webserveren på den maskine nede, eller er min hjemmeside flyttet til en anden adresse?

Forebyg den næste

En afvist forbindelse er næsten altid en stoppet webserver, og en stoppet tjeneste er præcis det, et porttjek og et hjemmesidetjek udefra opdager inden for et minut. På din egen server giver serveragenten dig besked, når nginx eller Apache stopper, og en Quick Fix genstarter den, når dens konfigurationstest er bestået, til fast pris, uden at nogen logger ind klokken 3 om natten. Er selve konfigurationen ødelagt, reparerer en Deep Fix den.