Why am I getting a redirect error when trying to use www? non www works fine

July 5, 2016 418 views
LAMP Stack DNS WordPress Apache DigitalOcean Ubuntu

I'm moving our site to a new server. The site on our old shared hosting works great, it's just a little slow.

The problem I'm having is that after installing unbuntu/apache on the new server and transfering the site over, everything works great as long as I'm not using www in the wordpress settings.

When I switch to www, there is a redirect error:

I've created a server with the hostname signa.com as an a record and www as a cname record.

How can I figure out where the non www redirect is coming from?

I've tried to get help from the company I'm using for the server but they aren't able to solve this.

The live site is on our old host for now, so for Local testing of the new server, add this to your local host file: signa.com

  • wp_options in the db is both set to http://www.signa.com

    curl -I www.signa.com HTTP/1.1 301 Moved Permanently Date: Tue, 05 Jul
    2016 11:05:27 GMT Server: Apache/2.4.7 (Ubuntu) Location:
    http://www.signa.com/ Content-Type: text/html; charset=iso-8859-1

Virtual Host file:


<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

    ServerAdmin clint@jackrabbit.host
    DocumentRoot /var/www/
     <Directory /var/www/>
        AllowOverride All

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

<VirtualHost *:80>
     ServerName signa.com
     DocumentRoot /var/www/
<VirtualHost *:80>
     ServerName signa.com
     Redirect permanent / http://www.signa.com/


<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L] 
    RewriteCond %{HTTP_HOST} ^signa.com [NC] 
    RewriteRule ^(.*)$ http://www.signa.com/$1 [L,R=301] 




* The base configuration for WordPress
* The wp-config.php creation script uses this file during the
* installation. You don't have to use the web site, you can
* copy this file to "wp-config.php" and fill in the values.
* This file contains the following configurations:
* * MySQL settings
* * Secret keys
* * Database table prefix
* @link https://codex.wordpress.org/Editing_wp-config.php
* @package WordPress

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', '###');

/** MySQL database username */
define('DB_USER', '###');

/** MySQL database password */
define('DB_PASSWORD', '###');

/** MySQL hostname */
define('DB_HOST', '###');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

 * Authentication Unique Keys and Salts.
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 * @since 2.6.0
define('AUTH_KEY',         'HXwNcJjFAbNTKFeC4JpIERRBEVIvm46fTuh1QDuatKVcV8TH7cegrLAvAZVfeRAD');
define('SECURE_AUTH_KEY',  'F3P1lpoJMbIi4IgnZ1VTKdzvL4KzQXrxxeDy3odvdP5woK6U6zF3mzzXODVsnLjg');
define('LOGGED_IN_KEY',    'w7gxw3TqaL0MYy51fddCBhLUpS2RAKwEExpFFPM7xUVAa7HzyA5eccTRbSJFuStk');
define('NONCE_KEY',        'SNtHxZr8GrqE3qHJzAVtOcB0ZQ06dz6CnG9pS2PaOCMO1ioSTjQV1eilO8pAMvK8');
define('AUTH_SALT',        'sPbDhd6UcCNlcMEdQlRv0bZkP7Q4jz2TnWUPEE0oLqAnAbVXMpYRolTv8MZRXCRc');
define('SECURE_AUTH_SALT', 'lfRC1gtSHmnnRG4zg0R5er7TWzL7bJkSUcxhKtsHP3fHVdbLcxCjuZWoq1O79BCx');
define('LOGGED_IN_SALT',   'tvNY7YCd9kLE11FOj0U63kWUuEgLge7FRse6zyhjCEYvFMBMT3aTjrpqsIIwnTDk');
define('NONCE_SALT',       'ORlv569jegJEYIO3ZonOwGFX7nX12geVYXz0dDazwd9gHxcoY07u6RaEOcfM6vhV');


 * WordPress Database Table prefix.
 * You can have multiple installations in one database if you give each
 * a unique prefix. Only numbers, letters, and underscores please!
$table_prefix  = 'wp_';

 * For developers: WordPress debugging mode.
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 * For information on other constants that can be used for debugging,
 * visit the Codex.
 * @link https://codex.wordpress.org/Debugging_in_WordPress
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

define('UPLOADS', 'images' );
2 Answers

I believe that the issue may stem from this line in your Apache configuration:

Redirect permanent / http://www.signa.com/

WordPress itself will perform a redirect via .htaccess or when a request is received so this is not necessary in your configuration and may be the source of the redirect loop.

  • Thanks Ryan!

    Good grief, that was the problem.

    I was getting a white screen after deleting that block, so I added:

    <VirtualHost *:80>
         ServerName www.signa.com
         DocumentRoot /var/www/

    to declare that url's file path.

    I was talking to Digital Ocean support and they had recommended the same change which I had done but for some reason it wasn't working. Maybe I needed to reset the dns cache or apache to see the changes which I've just done.

    Thank you again!

    • You're completely correct, I missed that that VirtualHost did not have a DocumentRoot set.

      Whenever you make changes to your apache configuration you will need to restart the service. Apache only reads the configuration files on startup. Running a

      service apache2 restart

      should have your changes take effect.


Just wanted to hop in on this and request that you visit the URL below to regenerate your Keys & Salts since they are exposed in your initial post. These Keys & Salts are used by WordPress to secure data, such as passwords, and by exposing them, you're potentially providing information that could be used against you should someone wish to try.


Simply replace the following (I've stripped the Keys & Salts so they aren't in my reply):

define('AUTH_KEY',         '');
define('SECURE_AUTH_KEY',  '');
define('LOGGED_IN_KEY',    '');
define('NONCE_KEY',        '');
define('AUTH_SALT',        '');
define('SECURE_AUTH_SALT', '');
define('LOGGED_IN_SALT',   '');
define('NONCE_SALT',       '');

... with the output from the URL above.

Have another answer? Share your knowledge.