Question
Why is my server redirecting URLs without a trailing slash to the server's IP address instead of keeping the domain
- Posted on March 17, 2021
- WordPressApacheDigitalOceanLAMP Stack
Asked by Jreno
I’ve set up a droplet for a WordPress site using the provided 1-Click installer. This installs the latest LAMP stack along with Wordpress. I also created a SSL certificate for my site using certbot. I’ve modified my HTTP virtual host file to always perform a redirect to HTTPS.
Everything works as expected except for this one strange behavior. If the trailing slash on the requested URL is not provided by the user, the server performs a 301 redirect to a URL which replaces my domain with the server’s IP address. For example, requesting https://subdomain.domain.com/forum forces a redirect to https://11.22.33.44/forum/. Since my SSL certificate is tied to my domain, it causes a big warning to appear in the browser. I’ve noticed this behavior will always happen regardless of the sub-directory (i.e. will also happen if trying to access http://subdomain.domain.com/wp-includes).
The ONLY exception I’ve noticed with this is when I created a /test directory in the root and created a simple index.html file to display “Hello World”. Trying to access https://subdomain.domain.com/test worked as expected and added the trailing slash without a redirect.
I’ve tried countless things in the .htaccess files without luck. I’m not even confident these files will help. I’ve purposely put a line of garbage in them to see if they’re even active during this redirect and they’re not. The server won’t trigger an error unless I use a URL with a trailing slash. I’ve tried this experiment with the root .htaccess file as well as the one in my /forum directory. However, seeing as how my Hello World experiment was successful (without any .htaccess file), I’m really stumped!
Just for the full background, I already have a fully function site at “domain.com” with a shared hosting provider. I’m experimenting with a migration to DO using this droplet. I’m fiddling around with both sites in my browser, so I’m hoping this isn’t an issue with cookies.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Get our biweekly newsletter
Sign up for Infrastructure as a Newsletter.
Hollie's Hub for Good
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Become a contributor
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Hi,
I would consider an issue around caching rather than cookies. Web content might be cached by your web browser, network devices (e.g. home router), internet proxies, CDN etc. It would be quite good explanation on why request to newly-created https://subdomain.domain.com/test works fine. Imagine the scenario: you made some changes in Apache configuration and still got your web with IP in browser’s address bar. Then, you set up new site test, and it worked fine. So, your configuration changes brought expected result but you could see just cached content. To mitigate caching issues, I usually use two different browsers. One of them is intended just for testing the changes in web server configuration and website look. I set up this browser to delete all content (cache, cookies, addresses) during its closing. Once I change something and want to check how it works, I close the browser and open it again for a new test.
Referring to
.htaccessissue, I would double check if Apache configuration directive AllowOverride is set to ON in subdomain.domain.com vhost configuration. This directive enables configuration with.htaccessfile.