My domain is hosted on my own Debian bare-metal server at IONOS and uses Nginx. A few months ago, changes to this site stopped appearing: uploading, editing, or deleting files had no visible effect. A few days later, the entire site was replaced by a black page containing a strange console-like interface that we never deployed.
The domain still resolves to my server's public IP, the nameservers and DNS records have not changed, and my other domains and services on the same machine work normally. I can still access the expected files over FTP, but modifying them does not change what visitors see. IONOS also says they do not see anything unusual.
Could this be a compromised server, a malicious Nginx configuration, or some other virtual-host issue? How can I determine where the content is actually being served from?
3 Answers
This strongly suggests that the site or server was compromised, especially since the page contains a console-like interface and your file changes have no effect. First inspect the Nginx server block for this hostname and verify that its root or proxy_pass points to the directory or backend you expect. Also check included configuration files, symlinks, rewrite rules, and whether another virtual host is answering for the domain.
It is worth confirming that the domain registration has not expired or been transferred, but that is less likely if DNS still resolves directly to your server and other services behave normally. A more likely explanation is that Nginx is serving a different document root, routing to an unexpected upstream, or the affected site was altered independently of the files you are editing. Use the active Nginx configuration and access logs to identify exactly what handles the hostname.
The strange interface could be a web shell or another malicious payload rather than a normal replacement page. Treat the machine as potentially compromised: preserve logs, avoid trusting the existing installation, rotate credentials from a clean machine, check running processes and scheduled jobs, and compare the Nginx configuration with a known-good backup. If possible, take the affected service offline and rebuild it from clean images or backups instead of only deleting the visible files.
The server responds with HTTP 200 and identifies itself as Nginx, so the next step is checking the request from another network or machine and comparing the response. I’ll also inspect the active virtual-host configuration and logs to see which document root or upstream is handling the request.