ERR_CONNECTION_REFUSED: årsaker og hvordan du fikser det

Hva feilen betyr

Nettleseren fant adressen til serveren, sendte en tilkoblingsforespørsel til port 443 (eller 80), og serveren svarte «nei»: en TCP-tilbakestilling, som operativsystemet sender når ingen program lytter på den porten. Chrome viser ERR_CONNECTION_REFUSED («Nettstedet kan ikke nås»), Firefox «Kan ikke koble til», Safari «Safari kan ikke koble til tjeneren».

Dette er noe annet enn et tidsavbrudd (ingenting svarer i det hele tatt, vanligvis en brannmur som forkaster pakker eller en server som er av) og enn DNS_PROBE_FINISHED_NXDOMAIN (navnet løses ikke opp). En avvist tilkobling betyr: maskinen er oppe og kan nås, men webserveren på den kjører ikke, lytter på en annen port eller adresse, eller er blokkert av en brannmur som avviser i stedet for å forkaste.

Vanlige årsaker

1. Webserveren er stoppet. nginx eller Apache krasjet, klarte ikke å starte etter en konfigurasjonsendring, eller ble stoppet av en oppdatering. Den klart vanligste årsaken.
2. Webserveren lytter på feil adresse eller port. Etter en endring av listen-direktivene binder nginx seg bare til 127.0.0.1 eller bare til IPv4 mens DNS-posten peker på en IPv6-adresse.
3. En brannmur avviser porten. ufw, firewalld eller en sikkerhetsgruppe i skyen med en reject-regel for 80/443, ofte etter at noen har «herdet» serveren.
4. En ny server uten webserver. DNS-posten peker allerede på den nye IP-en, men nginx er ikke installert eller ikke startet ennå.
5. HTTPS er ikke satt opp. Port 80 fungerer, port 443 har ingen lytter, og nettleseren (eller en HSTS-oppføring) insisterer på HTTPS.
6. Lokale årsaker hos den besøkende. En proxy-innstilling som peker på en død proxy, en VPN, antivirusprogrammets «nettskjold», en oppføring i hosts-filen eller en nettleserutvidelse.

Hvis du er besøkende

1. Prøv nettsiden i et privat vindu og med en annen nettleser, som utelukker utvidelser og cache.
2. Sjekk proxy-innstillingene: Windows «Proxy-innstillinger», macOS Nettverk > Avansert > Proxyer. Slå av en manuell proxy du ikke bruker.
3. Slå av VPN og antivirusprogrammets nettbeskyttelse et øyeblikk.
4. Tøm DNS (ipconfig /flushdns, sudo dscacheutil -flushcache) i tilfelle bufferen din holder en gammel adresse til en nettside som er flyttet.
5. Prøv http:// i stedet for https:// én gang; fungerer det, er HTTPS på nettsiden ødelagt og eieren må fikse det.

Hvis det er din nettside: sjekk først

Kjør nettside-nede-sjekken. «Connection refused» utenfra bekrefter at selve serveren avviser. Logg deretter inn via SSH (at SSH fungerer mens nettsiden avviser, er i seg selv et sterkt hint: serveren er oppe, webserveren er det ikke).

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

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

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

Viser ss ingenting på 443, er webserveren nede eller ikke konfigurert for det. Viser den 127.0.0.1:443 i stedet for 0.0.0.0:443 eller *:443, lytter den bare lokalt.

Løsninger på din egen server

1. Start webserveren, og les hvorfor den stoppet

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

Klarer den ikke å starte, er årsakene nesten alltid en av disse:

• nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use): et annet program holder porten (Apache og nginx begge installert, eller en gammel prosess). sudo ss -tlnp | grep :80 navngir den; stopp den du ikke vil ha.
• [emerg] unknown directive eller unexpected "}": en syntaksfeil i en konfigurasjonsfil. sudo nginx -t skriver ut filen og linjen.
• cannot load certificate: en sertifikatfil ble slettet eller fornyet til en annen sti. Sjekk ssl_certificate-linjene mot det som ligger på disken.
• Too many open files eller en full disk: df -h, df -i.

Apache: sudo apachectl configtest, deretter sudo journalctl -u apache2 -n 50. De samme kategoriene gjelder; AH00558 (could not determine server name) er bare en advarsel, ikke årsaken.

Test alltid før du laster på nytt, og last på nytt i stedet for å starte på nytt når det er mulig:

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

2. Lytt på riktig adresse

I nginx server-blokken trengs begge disse for IPv4 og IPv6:

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

Har DNS en AAAA-post, men serveren lytter ikke på IPv6 (eller har ingen IPv6-tilkobling), får besøkende på IPv6 en avvist tilkobling mens alle andre er fine. Enten får du den til å lytte, eller du fjerner AAAA-posten.

3. Åpne brannmuren

# 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 skyserver sjekker du også leverandørens sikkerhetsgruppe eller nettverksbrannmur i kontrollpanelet; en regel der er usynlig fra innsiden av serveren.

4. Sett opp HTTPS hvis bare port 80 svarer

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

Certbot legger til 443-server-blokken og omdirigeringen. Sjekk deretter med SSL-sjekken at kjeden er komplett.

5. Etter en serverflytting

Sørg for at webserveren på den nye maskinen er installert, konfigurert for domenet og startet før du endrer DNS. Har du allerede endret det: installer og start den nå, eller pek posten tilbake til den gamle serveren til den nye er klar.

Når det er hosting-leverandørens problem

På delt hosting betyr en avvist tilkobling at hosting-leverandørens webserver er nede for noden din, eller at de flyttet deg til en ny IP uten å oppdatere DNS. Send:

Hei, nettsiden min example.com har returnert «connection refused» på port 80 og 443 siden omtrent 20:15 UTC. Domenet løses opp til 203.0.113.10. Jeg har ikke endret noe i kontoen min. Er webserveren på den maskinen nede, eller er nettsiden min flyttet til en annen adresse?

Forhindre neste gang

En avvist tilkobling er nesten alltid en stoppet webserver, og en stoppet tjeneste er nettopp det en portsjekk og en nettsidesjekk utenfra merker innen et minutt. På din egen server varsler serveragenten deg når nginx eller Apache stopper, og en Quick Fix starter den på nytt etter at konfigurasjonstesten er bestått, til fast pris, uten at noen må logge inn klokken 03 om natten. Er selve konfigurasjonen ødelagt, reparerer en Deep Fix den.