[Bug]: Incorect www redirects: 302 -> 307 -> 200

[monolithed]

Error Message and Logs

https://www.*, https://*. -> 302 -> 200
https://*.,https://www.* -> 307 -> 302 -> 200 🤯

1. Why are they temporary?
2. How do I set a permanent redirect using 301 or 308 instead?

I migrated 6 websites and Google excluded all of them from indexing — basically banned them — because of these redirects!

I've previously mentioned that the current approach to www redirection is quite confusing.
It requires paying attention to the order of domains and understanding the exact function of buttons like Generate Domain, Set Direction, Save, Restart, and Redeploy.

Wouldn't it be more user-friendly to simplify this process, as it's done in platforms like Vercel or Dokploy, where managing this basic option is straightforward and avoids unnecessary uncertainty or bugs?

[djsisson]

@monolithed yes you're right the middleware setup is not great

firstly the order of the domains shouldn't matter as the same set of labels get generated, in your 2nd example there was a space

302 is http to https
307 will be www to non-www
neither of these are marked as permanent

if you wish to use permanent then you can either edit the middleware labels to add permanent, or add your own dynamic file for your domain

[monolithed]

@djsisson, until you in another ticket told me that I had to add 'www' separated by a comma, I had no idea about this trick. There's no mention anywhere about the order or spaces between domains either. It's not something you can just figure out intuitively, is it?

302 is http to https
307 will be www to non-www

There’s no hard rule — both 301 and 308 redirects can be used with any protocol. However, there’s another pattern: when redirecting from www using a 302, search engines tend to penalize the site — which is exactly what happened in my case.

302 / 307 are temporary redirects. They tell browsers and bots: “This resource is temporarily available at another address. Try later”
301 / 308 , on the other hand, are permanent redirects, and they are the ones most commonly http:// to https://. They tell search engines: “Always use HTTPS and pass full SEO value to the new URL".
The same logic applies when redirecting from www to non-www (or the other way around). In such cases, 301 or 308 should generally be used.

I prefer to use 308 because it doesn’t allow the request method to change — POST stays POST, GET stays GET. It’s stricter and more predictable.

if you wish to use permanent then you can either edit the middleware labels to add permanent, or add your own dynamic file for your domain

Thanks, I wasn’t aware of this case. I'll try it.
I really wish the whole process could be simplified to a single click — like it is in Vercel and Dokploy.

[monolithed]

I've configured the redirects correctly via Traefik, but even that raised a bunch of questions:

1. Why does unchecking Readonly labels reset all changes to their default state? Then what’s the point of having a Reset Labels to Defaults button if this toggle already does that? It feels similar to the Redeploy and Restart buttons — they seem to do the same thing every time, and it’s unclear when you should use which.

- traefik.http.middlewares.0-f8sok8g84kg8k84k0c8gws4c-to-non-www.redirectregex.permanent=false
+ traefik.http.middlewares.0-f8sok8g84kg8k84k0c8gws4c-to-non-www.redirectregex.permanent=true

2. Why not allow label values to be edited without having to disable the Readonly toggle first?
   The real issue is that I can’t edit labels like Enable Gzip Compression or Force HTTPS unless I uncheck Readonly labels. But if the toggle is already off, the interface still doesn’t let me edit those fields. So I have to re-enable Readonly labels and then disable it again — but doing that resets the entire config to defaults, which is frustrating.

I really like this platform but in many places it feels like walking through a maze with traps.

Suggestions:

1. Replace common Traefik labels (like compression, HTTPS, etc.) with proper checkboxes / toggles / inputs where applicable.
2. Fix the bug where changing the Readonly labels toggle resets the current label config.
3. Rename Readonly to something like Lock, so it only prevents editing but doesn’t affect or reset the configuration.

[Cinzya]

Readonly labels doesn't mean you lock it from being edited, but you prevent Coolify from handling the label configuration. So when you enable it, that means Coolify will generate it's own labels again.

However, it should respect the setting you applied under Advanced. It looks like it doesn't matter whether or not you disable any of those settings, regardless if readonly labels are enabled. At least from what I can see here testing on Coolify v4.0.0-beta419.

But I understand and agree, that this can be confusing. Might be good to make this a seperate Improvement Request in the GitHub Discussions.

[monolithed]

However, it should respect the setting you applied under Advanced. It looks like it doesn't matter whether or not you disable any of those settings, regardless if readonly labels are enabled. At least from what I can see here testing on Coolify v4.0.0-beta419.

I may have phrased it poorly. In my opinion, the Readonly feature currently causes more confusion and potential bugs than it provides value. I would suggest removing it and allowing label states to be changed directly via checkboxes.
Additionally, I would add a lock on the Traefik config to prevent accidental changes — ideally, this could be implemented as a diff.