ERR_CONNECTION_REFUSED: de server weigert de verbinding

Wat de fout betekent

De browser heeft het adres van de server gevonden, heeft een verbinding gevraagd op poort 443 (of 80) en de server heeft “nee” gezegd: een TCP-resetpakket, het antwoord dat vertrekt als geen enkel programma op die poort luistert. Chrome toont ERR_CONNECTION_REFUSED onder “Deze site is niet bereikbaar”, Firefox zegt “Kan geen verbinding maken”, Safari “Safari kan geen verbinding maken met de server”.

Het is geen ERR_CONNECTION_TIMED_OUT (geen enkel antwoord: een firewall die pakketten laat vallen of een machine die uit staat) en geen DNS_PROBE_FINISHED_NXDOMAIN (de naam wordt niet gevonden). Een geweigerde verbinding betekent: de machine draait, maar de webserver staat stil, luistert op een andere poort of een ander adres, of een firewall weigert in plaats van te negeren.

Veelvoorkomende oorzaken

1. De webserver staat stil. nginx of Apache is gecrasht, is na een configuratiewijziging niet meer gestart of is door een update gestopt. Het meest voorkomende geval.
2. Verkeerd adres of verkeerde poort. Na een wijziging in de listen-regels luistert nginx alleen op 127.0.0.1 of alleen via IPv4, terwijl het DNS ook naar een IPv6-adres wijst.
3. Een firewall weigert de poort. ufw, firewalld of een security group in de cloud met een reject-regel voor 80 en 443.
4. Een nieuwe server zonder webserver. Het DNS wijst al naar het nieuwe IP-adres, maar daar draait nginx nog niet.
5. HTTPS niet ingesteld. Poort 80 antwoordt, op 443 luistert niemand en de browser (of een HSTS-vermelding) eist HTTPS.
6. Oorzaken bij de bezoeker. Een dode proxy, een VPN, de “webbescherming” van een virusscanner, een regel in het hosts-bestand, een browserextensie.

Als je bezoeker bent

1. Open de site in een incognitovenster en in een andere browser, om extensies en cache uit te sluiten.
2. Controleer de proxy-instellingen: Windows “Proxyinstellingen”, macOS Netwerk > Geavanceerd > Proxy’s. Schakel een handmatige proxy uit die je niet gebruikt.
3. Zet VPN en de webbescherming van je virusscanner even uit.
4. Leeg de DNS-cache (ipconfig /flushdns op Windows, sudo dscacheutil -flushcache op macOS, sudo resolvectl flush-caches op Linux): misschien bewaart die nog het oude adres van een site die is verhuisd.
5. Probeer http:// in plaats van https://; kom je zo wel binnen, dan is de HTTPS van de site kapot en moet de eigenaar dat oplossen.

Als het je eigen site is: eerst controleren

Open de Website down checker. “Verbinding geweigerd” van buitenaf bevestigt dat het echt de server is die weigert. Log daarna in via SSH; al het feit dat SSH antwoordt terwijl de site weigert, zegt iets: de machine draait, de webserver niet.

# draait de webserver?
systemctl status nginx
systemctl status apache2

# wat luistert er op 80 en 443?
sudo ss -tlnp | grep -E ':80 |:443 '

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

Toont ss niets op 443, dan staat de webserver stil of gebruikt hij die poort niet. Toont het 127.0.0.1:443 in plaats van 0.0.0.0:443 of *:443, dan luistert hij alleen lokaal.

Oplossingen op je eigen server

1. De webserver starten en lezen waarom hij stilstond

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

Start hij niet, dan is het bijna altijd een van deze gevallen:

• bind() to 0.0.0.0:80 failed (98: Address already in use): een ander programma bezet de poort (Apache en nginx samen geïnstalleerd, of een oud proces). sudo ss -tlnp | grep ':80 ' noemt het bij naam; stop het programma dat je niet wilt.
• [emerg] unknown directive of unexpected "}": een syntaxfout. sudo nginx -t wijst bestand en regel aan.
• cannot load certificate: een verwijderd certificaat of een vernieuwing op een ander pad. Vergelijk de ssl_certificate-regels met wat er op schijf staat.
• Too many open files of een volle schijf: df -h, df -i.

Apache: sudo apachectl configtest, daarna sudo journalctl -u apache2 -n 50. Dezelfde categorieën gelden; AH00558 (could not determine server name) is alleen een waarschuwing, niet de oorzaak.

Test altijd voordat je herlaadt, en herlaad in plaats van te herstarten:

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

2. Op het juiste adres luisteren

Het server-blok van nginx moet op IPv4 én IPv6 luisteren:

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

Heeft het DNS een AAAA-record maar luistert de server niet op IPv6, dan worden bezoekers met IPv6 geweigerd en komen de anderen gewoon binnen. Luister op IPv6 of verwijder het AAAA-record.

3. De firewall openen

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Op een cloudserver controleer je ook de security group of de netwerkfirewall in het paneel van de aanbieder: een regel daar is vanaf de server onzichtbaar.

4. HTTPS instellen als alleen poort 80 antwoordt

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

Certbot maakt het 443-blok en de doorverwijzing aan. Controleer daarna de keten met de SSL checker.

5. Na een serververhuizing

Installeer, configureer en start de webserver op de nieuwe machine voordat je het DNS omzet. Heb je het DNS al omgezet: installeer en start de webserver nu, of zet het record terug naar de oude server tot de nieuwe klaar is.

Als het probleem bij je hostingprovider ligt

Op shared hosting betekent een geweigerde verbinding: de webserver van de provider is uitgevallen, of je site is naar een nieuw IP-adres verhuisd zonder dat het DNS is bijgewerkt. Stuur dit bericht:

Goedemiddag, mijn website example.com geeft sinds ongeveer 20:15 uur (UTC) “verbinding geweigerd” op poort 80 en 443. Het domein wijst naar 203.0.113.10. Ik heb zelf niets gewijzigd. Staat de webserver op die machine stil, of is mijn site naar een ander adres verplaatst?

Zodat het niet opnieuw gebeurt

Een geweigerde verbinding is bijna altijd een stilstaande webserver, precies wat een controle van buitenaf meteen opmerkt. Op je eigen server waarschuwt de serveragent je zodra nginx of Apache stopt, nog voordat een bezoeker het merkt.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang herstart de Quick Fix de webserver als zijn configuratietest slaagt, tegen een vaste prijs, 24 uur per dag, ook in het weekend. Kapotte configuratie? De Deep Fix repareert die, per blok van 15 minuten; de schatting is de bovengrens.