Old Multisite Domains Still Serving Default Forum After Disabling Multisite

[Abdelrahman_MoHamed]

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:

1. Show an error (since they are no longer configured)
2. 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:

1. Removed multisite settings from discourse.conf and database
2. Restarted Discourse and verified the app.yml settings
3. 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:

1. How can we properly remove the old domains so they do not serve the default forum?
2. Do we need to adjust Nginx/Traefik settings, Cloudflare settings, or is there a Discourse-specific configuration we missed?

Nginx Config

[pfaffman (Jay Pfaffman)]

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.

[Abdelrahman_MoHamed]

Thanks @pfaffman , We attempted to switch from a multisite setup to a standard install, but the issue still persists.

What We Did:

1. Removed the Discourse Installation:

• Deleted the entire /var/discourse directory.

2. Reinstalled Discourse:

• Cloned the Discourse repo again.
• Recreated app.yml with the necessary configurations.

3. Rebuilt the App:

• Ran ./launcher rebuild app.

4. 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

Questions:

1. Could the issue be related to not restoring a database backup?
2. Are there additional steps needed to clean up old multisite configurations?
3. 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!

[pfaffman (Jay Pfaffman)]

@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

[RGJ (Richard - Communiteq)]

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.

@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.

[pfaffman (Jay Pfaffman)]

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!

@RGJ

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.

@RGJ

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

My guess is that the app.yml still has something like this:

@pfaffman

   # 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;"

[RGJ (Richard - Communiteq)]

@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.

[Abdelrahman_MoHamed]

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.

1. 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?

2. Discourse Debugging: Are there any logs or commands we can run inside the container to confirm that Discourse is handling hostnames correctly?

3. 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!

[RGJ (Richard - Communiteq)]

@RGJ

Cleaning up your old configuration is not a workaround, it is the solution.

Here’s a pointer.

[pfaffman (Jay Pfaffman)]

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.

[Abdelrahman_MoHamed]

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 ?

[Abdelrahman_MoHamed]

We already removed old domains but yes , they were having orange button enabled , the issue now if anyone got our server IP and a record there with enabling proxy option it will server our site with there domain

[pfaffman (Jay Pfaffman)]

You should run discourse-setup to make sure that you really have a standard installation. If you paste your old app.yml then you might have something in there that does not belong. I’m still not quite convinced that you have a standard setup.

@Abdelrahman_MoHamed

the issue now if anyone got our server IP and a record there with enabling proxy option it will server our site with there domain

I’m still not convinced that’s the case, but if it is, there’s nothing you can do about it.

[Jagster (Jakke Lehtonen)]

@Abdelrahman_MoHamed

if anyone got our server IP

The most of the world’s server IP’s are public. That is kind of the point of IP-system.

[Abdelrahman_MoHamed]

I really wanna thank you @pfaffman @RGJ, now it’s clean and almost good

The issue we are facing now is that all branding pictures have gone and sthe ame for some user’s images.

The branding data is ok I can download it from the old server but what about the users’s images and all site images also missing

New Server

Old Server

NOTES:

• we have followed the migration steps by running discourse remap to the same domain and rake posts:rebake
• Could it be related to multisite history so we need a specific remap according to this link
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

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.

[Jacob_Peebles]

Looking at the missing images they appear to have a ‘nested’ url, here is one:

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

And @pfaffman this was in fact the main site in the multisite setup.

CC: @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob_Peebles

/user_avatar/forum.mamapedia.com/

Hmm. Well, if it were the main site, I’d expect that path to be https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, but that doesn’t work either.

If you’ve still got the old site, I’d take a backup of this one and restore it on the new site.

[Abdelrahman_MoHamed]

Thanks @pfaffman , what I have done so far seems working.

I got into the old server and moved the data form /var/discourse/shared/standalone/uploads/default to the same path on the new server and all user avatars and posts came back

The new issue is that site branding is not working even if I try to update it.

Here is a one-minute screen record
https://www.veed.io/view/89c9e122-57bd-40b3-a5c5-d510a56973e4?panel=share

[Jacob_Peebles]

Checking back here to see if anyone has any ideas. We are very close to closing this out on our end, just need some assistance in trouble shooting the ‘non-logo’ saving issue. Thanks in advance for any ideas to solve it!