The site does not open

When the site on your BLACKBOX server does not open, go through the checks below in order: each one rules out one cause. You run the commands in steps 1, 2 and 9 and the three curl tests at the end on your own computer; you run all the others on the server, over SSH, as root. The server's address is in the “IP” field of its card on the “My Servers” page of the app.blackbox.md panel (app.blackbox.md/my-servers, sidebar → “Infrastructure” → “My Servers”). The panel has no settings for the web server, the firewall or certificates.

Available to: anyone with root SSH access to a BLACKBOX server. Other ports in the network filtering: on request, through support.

In the commands, replace DOMAIN with your domain and SERVER_IP with the server's address.

In short: what your browser shows

Step 1. DNS: the domain points to the server

On Linux or macOS:

dig +short DOMAIN
dig +short www.DOMAIN
dig +short DOMAIN AAAA

On Windows:

nslookup DOMAIN

The first two commands must show SERVER_IP (if www is a CNAME, the name it points to appears first, for example DOMAIN.). The third must show nothing; Cloudflare addresses appear only when the Cloudflare proxy is on. An AAAA record left over from your old hosting sends some of your visitors to a different server: delete it.

Step 2. The server is running

ssh root@SERVER_IP

If you can connect, the server is on and reachable from the network. If you can't: I can't connect over SSH. The panel does not show whether the server is running; if you stopped it with “Stop”, start it with “Start” on its card (Rebooting, stopping and starting a server).

Step 3. The web server is running and listening on 80 and 443

1. Check the service. For Apache, type apache2 (Ubuntu, Debian) or httpd (AlmaLinux, CentOS Stream) instead of nginx. The Active: line must show active (running).

   systemctl status nginx

2. If it shows inactive (dead) or failed, test the configuration (you should see “syntax is ok” and “test is successful”; otherwise the output shows the file and the line with the error), then start the service and enable it to start when the server boots:

   nginx -t
   systemctl enable --now nginx

   For Apache, the test shows “Syntax OK”:

   # Ubuntu and Debian
   apache2ctl configtest
   # AlmaLinux and CentOS Stream
   apachectl configtest

3. Check what is listening on ports 80 and 443:

   ss -tlnp | grep -E ':80|:443'

If the site opens on the IP address but the domain shows the default page, server_name (nginx) or ServerName/ServerAlias (Apache) does not include DOMAIN and www.DOMAIN. A full disk also causes errors: The server's disk is full.

Step 4. The system firewall allows 80 and 443

BLACKBOX does not turn on the system firewall on a new server. If you turned it on yourself, check it.

Ubuntu and Debian

ufw status

Status: inactive means that ufw is not blocking anything. If the status is active, the list must include 80 and 443 (for example 80,443/tcp ALLOW Anywhere, Nginx Full or Apache Full). If it doesn't:

ufw allow 80,443/tcp

AlmaLinux and CentOS Stream

firewall-cmd --list-all

“FirewallD is not running” means that firewalld is not blocking anything. If it is running, the services: line must include http and https. If it doesn't:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload

Warning Customers have no web or VNC console: the server is managed only over SSH. Do not delete the rule for port 22, and keep a second SSH session open while you change the firewall. Details: Firewall: network filtering and ufw/firewalld on the server.

Step 5. The port is open in the network filtering

Traffic to the server also passes through network filtering managed by BLACKBOX. On a new server, it lets through SSH (22), HTTP (80), HTTPS (443) and ping; the panel has no firewall settings. An application on another port, for example 3000, 8000 or 8080, is not reachable from the internet, even if the port is allowed in ufw or firewalld: the request ends in a timeout. You have two options:

• recommended: put nginx in front of the application, on 80 and 443: Node.js, Python and other services: nginx as a reverse proxy;
• ask support to open the port: give the server's IP address, the order number (BBX-…), the port, the protocol (TCP or UDP) and what you need it for.

Step 6. The application is listening on the right address

Check which address the application listens on (here, port 3000) and whether it responds on the server:

ss -tlnp | grep ':3000'
curl -I http://127.0.0.1:3000

• 127.0.0.1:3000: the application accepts connections only from the server itself. This is correct behind nginx (proxy_pass http://127.0.0.1:3000), but the application is not reachable directly from outside.
• 0.0.0.0:3000 or *:3000: the application accepts connections from outside, provided the port is also open in the network (step 5).
• No line: the application is not running or uses a different port; check its logs.

If the application responds on 127.0.0.1 but the site shows 502 Bad Gateway, check the address and port in proxy_pass. On AlmaLinux and CentOS Stream, “(13: Permission denied)” in /var/log/nginx/error.log means that SELinux is blocking the connection:

setsebool -P httpd_can_network_connect 1

A container published with -p 127.0.0.1:8080:80 likewise listens only locally: Installing Docker and Docker Compose.

Step 7. The HTTPS certificate is valid

certbot certificates

For the site's certificate, Domains: must include DOMAIN (and www.DOMAIN, if you use it), and Expiry Date: must end with (VALID: … days), not (INVALID: EXPIRED). “No certificates found.” means that no certificate has been issued on the server. If the certificate has expired, test the renewal, renew it and reload the web server (for Apache, apache2 or httpd instead of nginx):

certbot renew --dry-run
certbot renew
systemctl reload nginx

Curl test 2 shows which certificate a visitor actually receives. If you still see the old one, the web server was not reloaded or the configuration for port 443 points to other files. For certbot errors, see Web server with HTTPS: nginx or Apache and Let's Encrypt. For a commercial certificate, see SSL certificates: free (Let's Encrypt) and commercial.

Step 8. Cloudflare errors

If the domain goes through the Cloudflare proxy (the “Proxied” checkbox is checked on the record on the panel's “DNS” page, or the proxy is turned on directly in your Cloudflare account), Cloudflare connects to your server and shows its own error page when it cannot.

You choose the SSL mode in your Cloudflare account, under “SSL/TLS”; the panel's “DNS” page does not change it. Choose “Full (strict)” once the server has a valid certificate (Cloudflare documentation on SSL modes). To check the server without Cloudflare, run curl test 3 or temporarily uncheck “Proxied”.

Step 9. Browser cache and HSTS

• Open the site in a private window, in another browser or from another network (for example, over mobile data), and compare the result with the curl tests below.

• After a DNS change, clear the DNS cache on Windows:

  ipconfig /flushdns

• HSTS: a site that has sent the Strict-Transport-Security header opens only over HTTPS, and the browser does not let you click past a certificate error. The fix is a valid certificate (step 7).

Three curl tests

Run them on your own computer. In Windows PowerShell, type curl.exe instead of curl.

1. The web server responds on the IP address, without DNS:

   curl -I http://SERVER_IP

   Any HTTP response (200, 301, 403, 404): the server, the network and port 80 are fine. An immediate error (Connection refused, Couldn't connect to server): nothing is listening on port 80 (step 3). A timeout after a long wait: the packets are being dropped (steps 2, 4, 5).

2. What a visitor gets:

   curl -vk https://DOMAIN

   -k continues even if the certificate is not valid. Connected to DOMAIN (…) port 443 shows the address the request reached. subject: and expire date: show the name in the certificate and its expiry date (curl on Windows may not show them). The < HTTP… line shows the response code.

3. Your server, bypassing DNS and Cloudflare (--resolve sends the request straight to SERVER_IP, with the domain name):

   curl -I --resolve DOMAIN:443:SERVER_IP https://DOMAIN

Tip If test 3 succeeds but test 2 does not, the server is fine: the problem is in DNS (step 1) or in Cloudflare (step 8). If test 3 gives a certificate error, fix the certificate (step 7).

Logs

The last lines of the web server's log and of the service's log:

tail -n 50 /var/log/nginx/error.log
journalctl -u nginx -n 50 --no-pager

Application logs: for a systemd service, use the first command; for a container, the second; for Docker Compose, the third, run from the project directory.

journalctl -u SERVICE_NAME -n 100 --no-pager
docker logs --tail 100 CONTAINER_NAME
docker compose logs --tail 100

When to write to support

If all the checks pass and the site still does not open from outside, write to us: Opening a support ticket. Include the domain, the server's IP address, the order number (BBX-…), the results of the three curl tests and what you have already checked.

Frequently asked questions

The site was working, then it stopped, and I didn't change anything. Common causes are an expired certificate (step 7), a full disk (The server's disk is full) and a stopped application (steps 3 and 6). If the problem started after a reboot, the service was probably not enabled at startup: enable it for the web server and for the application, as in step 3.

The site works on my phone, but not on my computer. The cause is on your computer or in your network: the DNS or browser cache, or an old entry for the domain in the hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux and macOS). See step 9.

I have a “VPS hosting” plan with a control panel. If a control panel runs on the server, you manage the sites, the web server and the certificates from it; do not install another web server on top of it. The dig and curl tests still apply. Ask support which panel is installed and how to log in to it: “VPS hosting” plans with a control panel.