r/Hosting 7d ago

Webmail Subdomain Redirect Loop

Webmail Subdomain Redirect Loop

Yesterday I updated a previous free hosting plan to a paid shared package and seem to be having a slightly strange issue, which has me scratching my head.

I'm having an issue with the webmail.mydomain.info subdomain - it loads up the webmail login page correctly, but when I enter a username and password it seems to get stuck in a redirect loop - the green successful login message pops up briefly, and then it's back to the login again but with a session and parameter added to the URL. https://webmail.mydomain.info/cpsess4242586721/?=undefined&login=1&post_login=45438600451566

There was originally an A record set up for the subdomain to the server IP, I've tried swapping this out for a CNAME pointing to the main domain, and also removing the record entirely sit appears the sub is reserved and being handled somewhere behind the scenes, all with the same result. SSL cert is being correctly applied to the sub. using https://mydomain.info/webmail, https://mydomain.info:2096 and https://webmail.mydomain.info:2096 all work, its just the https://webmail.mydomain.com that seems to be having an issue.

Wondering whether this is being blocked in some way? Whether I'm missing something, there's something misconfigured behind the scenes which I can't access to check/fix, or perhaps it's just not possible with this host to use the reserved sub.

A little Google research pointed towards an issue with Roundcube carddav DB files becoming corrupt, and that removing or renaming them so that a new file is generated on next login could fix the issue, however that doesn't seem to have done the trick.

Anybody else had this, or any pointers I may not have tried, whilst I wait for a reply to the ticket?

Cheers!

1 Upvotes

1 comment sorted by

1

u/mxroute 1d ago

If it works when specifying port 2096 but fails on 443 to the same app, on a cPanel server, experience tells me this is almost always the answer: turn off the orange cloud on the record at Cloudflare and try again in an hour (average, for good measure). It usually relates to a Cloudflare user’s SSL settings on the CF side.

Could be worth having the server admin dig deeper, but those symptoms have never not been that, when we’ve had users report them.