I can no longer add domains – cannot be accessed via HTTP – redirected to the main domain

What type of hardware are you using: VPS bought online
What YunoHost version are you running: 12.1.39
How are you able to access your server: The webadmin
SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: no

Describe your issue

For the past few days, I have been unable to transfer domains I own to my YunoHost server. As part of a switch to a new hosting provider, I need to transfer various domains to my YunoHost server (VPS). I had booked this new VPS on 2 April, installed YunoHost on it and added two domains. Everything went smoothly. Let’s Encrypt certificates were also generated without any error messages. On 6 April, I added a few more domains. Everything went smoothly; I also corrected some minor issues in the DNS settings based on the diagnosis.

On 9 April, I carried out a tool upgrade, which also ran without any error messages. And a few hours later, I successfully added another domain.

On 15 April, as my old hosting package was due to expire soon, I wanted to migrate the remaining domains to the new VPS with YunoHost. But suddenly, without me having changed anything in the configuration, this is no longer possible. The addition via the web interface completes, but returns an error message stating that a Let’s Encrypt certificate could not be created. In the diagnostics, under the ‘Web’ section, a ‘fatal’ error message appears stating that the domain is not accessible via HTTP from the internet.

If I access the domain from the terminal using curl -I -4 http://<URL>, I receive the following output

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 17 Apr 2026 09:29:27 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https:///yunohost/admin

Attempting to re-initiate the Let’s Encrypt certificate creation via the web interface or CLI also fails (if I ignore the diagnostic error messages) with the error message stating that the certificate could not be signed.

Example for the added domain ‘psl.pepecyb.net’:

Verifying psl.pepecyb.net...

Challenge did not pass for psl.pepecyb.net: {“identifier”: {“type”: “dns”, “value”: “psl.pepecyb.net”}, “status”: “invalid”, “expires”: “2026-04-24T09:32:33Z”, “challenges”: [{“type”: “http-01”, “url”: “https://acme-v02.api.letsencrypt.org/acme/chall/3202980841/689522043051/6HDh3Q”, “status”: “invalid”, “validated”: “2026-04-17T09:32:35Z”, “error”:
 {“type”: “urn:ietf:params:acme:error:unauthorized”, “detail”: '2a02:c207:2319:7577::1: Invalid response from https://psl.pepecyb.net/yunohost/admin/: "\\n\\n \\n \\n

Certificate installation for psl.pepecyb.net failed !

Exception: The new certificate could not be signed

I have tested this for various domains; not a single one can be set up correctly on YunoHost anymore. The following error message always appears in the diagnostics

Web (web)

[ERROR] Domain psl.pepecyb.net appears unreachable via HTTP from outside the local network.
  - It looks like another machine (perhaps your internet router) responded instead of your server.
    1. The most common cause of this issue is that ports 80 (and 443) are not correctly forwarded to your server.
    
2. On more complex setups: ensure that no firewall or reverse proxy is interfering.

A Let’s Encrypt certificate cannot be created in this way. Furthermore, any domain added in this manner is automatically redirected to the YunoHost portal under the main domain.

For testing purposes, I have installed a ‘My Webapp’ under the domain mentioned here, psl.pepecyb.net. This worked without any problems or error or warning messages. However, it (i.e. the display of the placeholder text from index.html) is not accessible. When I try to access it in a web browser, a warning appears stating that it is a self-signed certificate. If I confirm that I trust this certificate as an exception, the content of the index.html from the ‘My Webapp’ is not displayed; instead, I am redirected back to the portal page under the main domain (pepecyb.net).

I spent half the night trying to get rid of this forced redirection, but always without success.

Note: Before the error occurred, I had a total of ten domains on the server. The YunoHost main domain pepecyb.net, as well as three subdomains of pepecyb.net, the domain hubzilla.hu, as well as four subdomains of hubzilla.hu, and the domain hubzilla.net. Adding the domains went smoothly and all installations under these domains are also accessible as normal; there is no redirection. The domains/subdomains are also correctly configured in my providers’ respective DNS zone management.

However, if I now configure the domain pericles.hu correctly in the zone management, for example, for use as a domain on my YunoHost, the addition process runs normally but then ends with an error message stating that the Let’s Encrypt certificate could not be signed. The diagnostics show only a single error message, namely that the domain is not accessible via HTTP. When the subdomain is accessed, there is always a redirect (302) to the main domain and thus to the portal, even if I explicitly access the domain only via http:// (reproducible with curl).

For some reason, new domains are suddenly (I haven’t changed the system configuration or performed any updates since the last successful domain addition and the error now occurring) being redirected to the main domain without exception.

What surprises me (and is a relief) is that this does not happen with the existing domains. I have compared the nginx configuration files (/etc/nginx/conf.d/…) of functioning domains and newly added non-functioning domains and found no significant differences.

After many hours of research, trial and error, and installing and uninstalling domains, I have now reached the end of my tether. I do not understand why all new domains are being forced to redirect, and above all, I have no idea where the problem lies.

What can I do? Where might the problem lie?

Share relevant logs or error messages

https://paste.yunohost.org/raw/agogosijuj

Can you share the link of the diagnosis?

https://paste.yunohost.org/raw/ulivurekay

I took another look at the operation logs to see what I’d been doing since the last successful addition of domains on 9 April and the first failed attempt to add domains.

Following the tools upgrade on 9 April, I had successfully added two domains: tty.pepecyb.net

and

f2b.pepecyb.net

This worked without any error messages.

I then installed the ‘Wetty’ app under the domain tty.pepecyb.net and the ‘Fail2Ban Webinterface’ app under the domain f2b.pepecyb.net.

However, I noticed that F2B was generating too much CPU load (for my liking) and that Wetty offered me no benefits. I therefore uninstalled both apps on 9 April and removed the domains as well. I subsequently deleted the entries for both domains in my host’s zone management too.

The only possible cause I can see for a misconfiguration leading to the current behaviour would be the uninstallation of ‘Fail2Ban Webinterface’ or ‘Wetty’. Although I also consider that it might have happened when I removed the two domains, as that was the first time I had ever removed domains.

Are there perhaps any insights into this? In other words, that the uninstallation routines of the two apps mentioned might have made some unforeseen changes to the system, or that removing domains could cause such a side effect in the system.

What is particularly strange is that, according to the diagnosis, newly added domains are not only inaccessible via http, but are also consistently and without exception redirected to the admin portal when accessed. And this happens with both http and https access. In the browser, you always end up at https:///yunohost/admin, and when accessing via curl, you get the following results (shown here using the non-functioning domain psl.pepecyb.net):

curl -I -4 http://psl.pepecyb.net/

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 17 Apr 2026 21:34:29 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https://psl.pepecyb.net/yunohost/admin
curl -I -4 -k https://psl.pepecyb.net/

HTTP/2 302
server: nginx
date: Fri, 17 Apr 2026 21:34:39 GMT
content-type: text/html
content-length: 138
location: https://psl.pepecyb.net/yunohost/admin
content-security-policy: upgrade-insecure-requests
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
permissions-policy: interest-cohort=()
strict-transport-security: max-age=63072000;

includeSubDomains; preload
referrer-policy: “same-origin”

I then took a look at the configurations under /etc/nginx and suspected that this might be due to the inclusion of /etc/nginx/conf.d/default.d/redirect_to_admin.conf. As a ‘brutal’ test, I temporarily renamed redirect_to_admin.conf (it has now been restored) so that it was no longer included, and after restarting nginx, I carried out the two tests with curl and accessed the domain in the browser. However, this had no effect. The redirection to /yunohost/admin remained in place.

Try removing the newly added domains then readd them

The error occurs consistently. I have already removed and re-added the domain several times. On a few occasions, I also ran the command yunohost tools regen-conf nginx --force before re-adding it. In some attempts, I also deleted the ‘remnants’ of the domain from the system (the remaining directories /etc/nginx/conf.d/psl.pepecyb.net.d, /etc/yunohost/certs/psl.pepecyb.net and /var/www/.well-known/psl.pepecyb.net).

Every time I add the domain, it results in the behaviour that triggers the error message in the diagnostics, prevents the installation of a Let’s Encrypt certificate, and redirects every request to the domain to psl.pepecyb.net/yunohost/admin.

And the same thing happens with other domains I have now added.

How did you remove this domain ?

I removed the domain using the web interface under Domains → psl.pepecyb.net → delete.

However, when you remove domains, ‘remnants’ always remain in the file system (this was also the case with my old YunoHost server, which I no longer run).

This is the (now empty) directory in /etc/nginx/config.d/<DOMAIN>.d

as well as the directory /var/www/.well-known/<DOMAIN> and the subdirectories autoconfig/mail it contains, none of which hold any files

and the file /var/www/.well-known/acme-challenge-private/<DOMAIN>.csr

These files can be deleted, which is what I did after the domain had been removed via the web interface.

I must apologise! The problem is solved! And I’m actually a bit embarrassed that I tried everything under the sun without thinking to try the most obvious solution first – or at least sooner.

Seriously: I’ve been fiddling around for three whole days now, trying out every possible change to the configuration, adding and deleting the domain (and others) what felt like 1000 times… pursuing the craziest theories. It was really exhausting and cost me a lot of sleep.

Then this evening I realised that there’s probably no central configuration file in YunoHost, but rather a lot of it is handled via an in-memory database. And perhaps something got mixed up there. And then it struck me that my VPS has been running for quite a while. Longer than the problems have been going on.

So I just gave it a go with a reboot, hoping that the database would be rebuilt / cleaned up / repaired when the system restarted completely.

And that was it! Everything’s working perfectly again. The diagnostics are now clean, and the domains that weren’t working are accessible as normal with a valid Let’s Encrypt certificate.

But there is one silver lining… I’ve still learnt a lot about YunoHost ‘under the bonnet’.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.