ERR_CONNECTION_REFUSED: orsaker och hur du åtgärdar det

Vad felet betyder

Webbläsaren hittade serverns adress, skickade en anslutningsbegäran till port 443 (eller 80), och servern svarade ”nej”: en TCP-återställning, som operativsystemet skickar när inget program lyssnar på den porten. Chrome visar ERR_CONNECTION_REFUSED (”Webbplatsen kan inte nås”), Firefox ”Det går inte att ansluta”, Safari ”Safari kan inte ansluta till servern”.

Detta skiljer sig från en timeout (ingenting svarar alls, oftast en brandvägg som släpper paket eller en server som är avstängd) och från DNS_PROBE_FINISHED_NXDOMAIN (namnet slås inte upp). En vägrad anslutning betyder: maskinen är uppe och nåbar, men webbservern på den körs inte, lyssnar på en annan port eller adress, eller blockeras av en brandvägg som avvisar i stället för att släppa.

Vanliga orsaker

1. Webbservern är stoppad. nginx eller Apache kraschade, kunde inte starta efter en konfigurationsändring eller stoppades av en uppdatering. Den överlägset vanligaste orsaken.
2. Webbservern lyssnar på fel adress eller port. Efter en ändring av listen-direktiven binder nginx bara till 127.0.0.1 eller bara till IPv4 medan DNS-posten pekar på en IPv6-adress.
3. En brandvägg avvisar porten. ufw, firewalld eller en säkerhetsgrupp i molnet med en reject-regel för 80/443, ofta efter att någon ”härdat” servern.
4. En ny server utan webbserver. DNS-posten pekar redan på den nya IP-adressen, men nginx är inte installerat eller inte startat än.
5. HTTPS inte uppsatt. Port 80 fungerar, port 443 har ingen lyssnare, och webbläsaren (eller en HSTS-post) insisterar på HTTPS.
6. Lokala orsaker hos besökaren. En proxyinställning som pekar på en död proxy, ett VPN, antivirusets ”webbsköld”, en post i hosts-filen eller ett webbläsartillägg.

Om du är besökare

1. Prova hemsidan i ett privat fönster och med en annan webbläsare, vilket utesluter tillägg och cache.
2. Kontrollera proxyinställningarna: Windows ”Proxyinställningar”, macOS Nätverk > Avancerat > Proxyservrar. Stäng av en manuell proxy som du inte använder.
3. Stäng av VPN och antivirusets webbskydd en stund.
4. Töm DNS (ipconfig /flushdns, sudo dscacheutil -flushcache) ifall din cache håller en gammal adress till en hemsida som flyttat.
5. Prova http:// i stället för https:// en gång; om det fungerar är hemsidans HTTPS trasigt och ägaren måste åtgärda det.

Om det är din hemsida: kontrollera först

Kör kontrollen av om hemsidan ligger nere. ”Connection refused” utifrån bekräftar att själva servern vägrar. Logga sedan in via SSH (att SSH fungerar medan hemsidan vägrar är i sig en stark ledtråd: servern är uppe, webbservern är det inte).

# körs webbservern?
systemctl status nginx
systemctl status apache2

# vad lyssnar på 80 och 443?
sudo ss -tlnp | grep -E ':80 |:443 '

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

Om ss inte visar något på 443 är webbservern nere eller inte konfigurerad för det. Om den visar 127.0.0.1:443 i stället för 0.0.0.0:443 eller *:443 lyssnar den bara lokalt.

Åtgärder på din egen server

1. Starta webbservern och läs varför den stoppade

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

Om den inte startar är orsakerna nästan alltid någon av dessa:

• nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use): ett annat program håller porten (både Apache och nginx installerade, eller en kvarglömd process). sudo ss -tlnp | grep :80 namnger den; stoppa den du inte vill ha.
• [emerg] unknown directive eller unexpected "}": ett syntaxfel i en konfigurationsfil. sudo nginx -t skriver ut filen och raden.
• cannot load certificate: en certifikatfil raderades eller förnyades till en annan sökväg. Jämför raderna ssl_certificate med det som finns på disken.
• Too many open files eller en full disk: df -h, df -i.

Apache: sudo apachectl configtest, sedan sudo journalctl -u apache2 -n 50. Samma kategorier gäller; AH00558 (could not determine server name) är bara en varning, inte orsaken.

Testa alltid innan du laddar om, och ladda om hellre än att starta om när det går:

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

2. Lyssna på rätt adress

I nginx server-blocket behövs båda dessa för IPv4 och IPv6:

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

Om DNS har en AAAA-post men servern inte lyssnar på IPv6 (eller saknar IPv6-anslutning) får besökare på IPv6 en vägrad anslutning medan alla andra klarar sig. Antingen låter du den lyssna, eller tar bort AAAA-posten.

3. Öppna brandväggen

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

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

På en molnserver, kontrollera också leverantörens säkerhetsgrupp eller nätverksbrandvägg i kontrollpanelen; en regel där är osynlig inifrån servern.

4. Sätt upp HTTPS om bara port 80 svarar

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

Certbot lägger till server-blocket för 443 och omdirigeringen. Kontrollera sedan med SSL-kontrollen att kedjan är komplett.

5. Efter en serverflytt

Se till att webbservern på den nya maskinen är installerad, konfigurerad för domänen och startad innan du ändrar DNS. Om du redan har ändrat det: installera och starta den nu, eller peka tillbaka posten på den gamla servern tills den nya är klar.

När det är ditt webbhotells problem

På delat webbhotell betyder en vägrad anslutning att webbhotellets webbserver är nere för din nod, eller att de flyttat dig till en ny IP-adress utan att uppdatera DNS. Skicka:

Hej, min hemsida example.com har returnerat ”connection refused” på port 80 och 443 sedan ungefär 20:15 UTC. Domänen slås upp till 203.0.113.10. Jag har inte ändrat något i mitt konto. Är webbservern på den maskinen nere, eller har min hemsida flyttats till en annan adress?

Förhindra nästa

En vägrad anslutning är nästan alltid en stoppad webbserver, och en stoppad tjänst är precis vad en portkontroll och en hemsidekontroll utifrån märker inom en minut. På din egen server larmar serveragenten dig när nginx eller Apache stoppar, och en Quick Fix startar om den efter att dess konfigurationstest har godkänts, till fast pris, utan att någon loggar in klockan 03 på natten. Om själva konfigurationen är trasig reparerar en Deep Fix den.