We were previously running a Discourse multisite setup with around 22 different forums. Recently, we decided to remove the multisite configuration and keep only the default site: Default site now: forum.mamapedia.com Removed old multisite domain: forum.employ.com (and 21 others) The Issue: Even after disabling the multisite setup, the old multisite domains can still serve the default forum (forum.mamapedia.com). For example: Visiting forum.mamapedia.com works as expected But visiting forum.employ.com still loads the Mamapedia forum We expected that old domains like forum.employ.com would either: Show an error (since they are no longer configured) Redirect properly or be completely inactive Setup Notes: We are using Cloudflare’s SSL certificates with the proxy option enabled (traffic does not go directly to our server). We can remove the A records for the old domains, but we really want to identify and fix the root cause instead of relying on a DNS-based workaround. Steps Taken So Far: Removed multisite settings from discourse.conf and database Restarted Discourse and verified the app.yml settings Cleared cache and tested in incognito mode Expected Behavior: forum.mamapedia.com should continue working forum.employ.com and other old domains should not serve the Mamapedia forum Questions: How can we properly remove the old domains so they do not serve the default forum? Do we need to adjust Nginx/Traefik settings, Cloudflare settings, or is there a Discourse-specific configuration we missed? [The image shows a snippet of a configuration file for setting up a Discourse forum with four worker processes and the specified host name 'forum.mamapedia.com'. (Captioned by AI)] Nginx Config [The image is a screenshot of an Nginx configuration file showing server settings and instructions to enable HTTPS with comments suggesting specific paths and parameters. (Captioned by AI)]

You need to switch to a standard install. The stuff you’ve done to make it be multisite is to make it possible for the server to serve a bunch of domains. If you make a new server and restore the backup then you can’t break anything since you’ll just switch back to the old one. The only catch is that you need to point the dns to the new server while you rebuild so it can get a certificate. And make cloudflare dns only.

Thanks @pfaffman , We attempted to switch from a multisite setup to a standard install, but the issue still persists. What We Did: Removed the Discourse Installation: Deleted the entire /var/discourse directory. Reinstalled Discourse: Cloned the Discourse repo again. Recreated app.yml with the necessary configurations. Rebuilt the App: Ran ./launcher rebuild app. Updated DNS: Pointed the domain to the new server. Set Cloudflare to DNS-only mode to allow SSL certificate issuance. Additional Issue with SSL: When we enabled SSL in app.yml and disabled Cloudflare proxy, we encountered the following issue even after enabling SSL [The image shows a computer screen displaying a warning page from a website called "forum.mamapedia.com" indicating that it does not support a secure connection and suggesting the user continue to the site and learn more about the warning. (Captioned by AI)] Questions: Could the issue be related to not restoring a database backup? Are there additional steps needed to clean up old multisite configurations? What’s the proper way to enable SSL in this setup without running into issues? Would appreciate any guidance from those who’ve done this before!

[image] Abdelrahman MoHamed: Recreated app.yml with the necessary configurations. Did you run discourse setup or do it by hand? Do you have the ssl and let’s encrypt templates? If you ran rebuilds a bunch of times with the orange cloud you could be rate limited

The reason this is happening is simple. Multisite will select a forum based on hostname. A non-multisite install will happily accept whatever hostname you point to it. So as long as you have all the old hostnames directed to that install, it will serve the remaining site on all those hostnames. [image] Abdelrahman MoHamed: We can remove the A records for the old domains, but we really want to identify and fix the root cause instead of relying on a DNS-based workaround. Having the old records point at your site, is the root cause. Cleaning up your old configuration is not a workaround, it is the solution.

OMG. I don’t remember the last time that I disagreed with you on a matter of fact. As a rule, when I see your avatar in a topic that I’ve commented on, I know that I’m going to learn something! [image] Richard - Communiteq: The reason this is happening is simple. Multisite will select a forum based on hostname That’s true. They claim, though, that they switched to a standard install. I don’t believe them. [image] Richard - Communiteq: A non-multisite install will happily accept whatever hostname you point to it. For several years now (but I think since let’s encrypt was available), on a standard install if you access it via any other hostname it’ll do a redirect (you can easily check by using the IP number and I just did another by setting forum.bigmouth.bass in /etc/hosts to a standard install and it redirected as expected. If you access it via https, which most browsers do by default now, you’ll get a certificate error. If all that was required to access your site via some other hostname was DNS then anyone could hijack your site by creating a DNS record pointing to your site. I think this is the magic: templates/web.ssl.template.yml main EOF install /dev/null /etc/nginx/conf.d/outlets/server/10-http.conf My guess is that the app.yml still has something like this: [image]Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy # do not redirect all hosts back to the main domain name - replace: filename: "/etc/nginx/conf.d/discourse.conf" from: /if \(\$http_host[^\}]*\}/m to: "" - replace: filename: "/etc/nginx/conf.d/discourse.conf" from: /return 301.*$/ to: "return 301 https://$host$request_uri;"

[image] Jay Pfaffman: I know that I’m going to learn something! Well TIL that I should update my facts more often! That code has been there since 2014 so I guess I was living waaay in the past. You’re completely right, it will redirect.

Thanks @RGJ , @pfaffman , We have checked app.yml, and there are no custom redirect configurations or overrides. However, our instance still isn’t redirecting unknown hostnames to the main domain. Nginx Configuration: Is there a way to verify if the redirect logic from templates/web.ssl.template.yml is actually being applied? Should we manually check the generated Nginx config inside the container? Discourse Debugging: Are there any logs or commands we can run inside the container to confirm that Discourse is handling hostnames correctly? Other Potential Causes: If app.yml is clean, what else might prevent the expected redirect behavior? Could Cloudflare or another setting be interfering? Would appreciate any pointers to dig deeper into this!

[image] Richard - Communiteq: Cleaning up your old configuration is not a workaround, it is the solution. Here’s a pointer.

Do the old domains all have the orange cloud turned on? Does riding off the orange cloud solve the problem? If so, then, as I expected all along, Richard is right and you need to clean up your setup. But if using cloudflare allows a bad actor (you in this case) to serve someone else’s site on their domain, that seems like a problem.

OK should I run ./discourse-setup after downloading discourse or should I paste my old app.yml after downloading and then run ./launcher rebuild app Which path should I take ?

Old Multisite Domains Still Serving Default Forum After Disabling Multisite

Product Support

pfaffman (Jay Pfaffman) February 12, 2025, 2:34pm 16

If this wasn’t the main site for the multisite then the path for the uploads is the name and the site and not default.

Topic		Replies	Views
Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy Sysadmins how-to , domains	24	5165	August 27, 2026
Discourse Multisite – Nginx (Inside Docker) Only Serving Default Site Product Support	1	131	March 19, 2025
WP SSO + Discourse Multisite Product Support	5	1049	June 2, 2021
Multisite installation ... in subdirectories? Product Support	3	944	May 20, 2020
Blank main page on one forum (subfolder + multisite install) Bug	5	1282	February 20, 2020

Old Multisite Domains Still Serving Default Forum After Disabling Multisite

Related topics