A redirect you added in cPanel usually isn't working for one of three reasons: the target field is missing a full URL, a cached response is hiding your change, or another rule in .htaccess is matching the request first. Start with the target field: double-check it includes the full URL with https://, not just a domain or path. If you typed example.com instead of https://example.com, the redirect can silently misbehave or loop. Delete the redirect and re-add it with the complete URL.
If the target format is correct, the next most likely cause is browser or edge caching serving you the old response, followed by a conflicting rule earlier in .htaccess that matches the request before your redirect gets a chance to run.
Check the target URL and match type
Open cPanel and go to Domains > Redirects. Confirm three things on the entry:
- The domain or subdomain selected in the dropdown matches what you're actually visiting.
- The Type is set correctly. If you're testing changes, use Temporary (302) first so a cached Permanent (301) from an earlier attempt doesn't get in your way.
- www. handling matches your intent. If you selected "Only redirect with www." but visitors are hitting the bare domain, the redirect won't fire. "Redirect with or without www." is usually what you want unless you have a specific reason to split behavior.
Clear the cache before you conclude it's broken
A 301 redirect is meant to be cached permanently by browsers. If you tested the URL, then changed or deleted the redirect, your browser may still be honoring the old cached response and never even asking your server. Test in a private/incognito window, or clear your browser cache, before assuming the fix didn't take. Curling the URL from a terminal (curl -I https://yourdomain.com/old-path) bypasses browser cache entirely and shows you the real response headers.
If you're running the domain through Cloudflare CDN, check the proxy status too. A cached page at the edge can serve a stored response before your server's redirect logic ever runs. Purge the cache from the Cloudflare CDN page in your Flashcloud portal after making redirect changes.
If you've also hand-edited .htaccess, or a plugin (common with WordPress SEO or caching plugins) has written its own rewrite rules, whichever rule appears first in the file wins for a matching request. Open File Manager, navigate to your site's root, and inspect .htaccess directly:
- Rules processed top to bottom; a broader pattern earlier in the file can intercept the request before it reaches your redirect.
- WordPress sites have a
RewriteRuleblock for permalinks that starts with# BEGIN WordPress. Your redirect should sit above this block. If it got added below it, WordPress's catch-all rule may handle the request first. - Check for duplicate or contradictory entries if you've added and removed the same redirect more than once through the UI.
If you're comfortable editing the file, you can move your redirect's rule block above the WordPress section manually. If you're not sure which lines belong to which tool, don't guess. Contact support first.
Confirm DNS is actually pointing here
A redirect that "does nothing" sometimes isn't a redirect problem at all: if the domain's DNS hasn't propagated to Flashcloud yet, or nameservers still point elsewhere, your request never reaches this server, so the redirect you configured never gets a chance to run. Run dig yourdomain.com and compare the result against your nameservers if you recently moved the domain.
When to contact support
Open a ticket from Support in the portal if the target URL and type are correct, cache is cleared, curl still shows the wrong response, and .htaccess has no conflicting rule. Include the exact source and destination URLs and the output of curl -I against the source URL. A real person will investigate further and can catch conflicts that aren't visible from cPanel alone.