Виртуальные хосты Apache с несколькими доменами

Question

Я пытаюсь выяснить, какая оптимальная конфигурация для файлов моего виртуального хоста, но у меня есть некоторые проблемы с ней.

В настоящее время у меня есть 2 домена: domain1.com и domain2.com

У меня есть 1 сервер на IP 000.000.000.001, который на самом деле хозяйничает все необходимые файлы. В этих файлах есть API (api.domain1.com) и фактический веб-сайт.

domain1.com использует сервер имен из Digital океана и использует следующие DNS записи:

A  @  000.000.000.001 
CNAME *  domain1.com. 

Для целей SEO Я хочу, чтобы перенаправить все запросы, которые не внесены в апи подобласти направить WWW .domain1.com. Однако я также ТОЛЬКО хочу, чтобы пользователи могли просматривать мой сайт (и API) через SSL-соединение, я не хочу, чтобы пользователи могли использовать его через HTTP, поэтому я пытаюсь перенаправить все эти запросы на использование HTTPS. Сертификаты предоставляются LetsEncrypt !. Их автоматизированные установки были внесены изменения в виртуальных хостах файлы и в настоящее время у меня есть 4 из них:

1. api.domain1.com.conf

   <VirtualHost *:80> 
       ServerName api.domain1.com 
   
       DocumentRoot /var/www/api.domain1.com/web 
   
       RewriteEngine on 
       RewriteRule^https://%{SERVER_NAME}%{REQUEST_URI} [L,QSA,R=permanent] 
   </VirtualHost> 
   

2. api.domain1.com-ль-SSL. конф

   <IfModule mod_ssl.c> 
   <VirtualHost *:443> 
       ServerName api.domain1.com 
   
       DocumentRoot /var/www/api.domain1.com/web 
   
       ExpiresActive On 
       /* ... */ 
   
       <Directory /var/www/api.domain1.com/web> 
        AllowOverride None 
        Order Allow,Deny 
        Allow from All 
   
        <IfModule mod_rewrite.c> 
          Options -MultiViews 
          RewriteEngine On 
          RewriteCond %{REQUEST_FILENAME} !-f 
          RewriteRule ^(.*)$ app.php [QSA,L] 
        </IfModule> 
       </Directory> 
   
       ErrorLog ${APACHE_LOG_DIR}/error.log 
       CustomLog ${APACHE_LOG_DIR}/access.log combined 
   
       SSLCertificateFile /etc/letsencrypt/live/domain1.com/cert.pem 
       SSLCertificateKeyFile /etc/letsencrypt/live/domain1.com/privkey.pem 
       Include /etc/letsencrypt/options-ssl-apache.conf 
       SSLCertificateChainFile /etc/letsencrypt/live/domain1.com/chain.pem 
   </VirtualHost> 
   </IfModule> 
   

3. domain1.com.conf

   <VirtualHost *:80> 
       ServerName domain1.com 
   
       Redirect 301/https://www.domain1.com 
   </VirtualHost> 
   

4. domain1.com-ле-ssl.conf

   <IfModule mod_ssl.c> 
   <VirtualHost *:443> 
       ServerName www.domain1.com 
       DocumentRoot /var/www/domain1.com 
   
       ExpiresActive On 
       /* ... */ 
   
       RewriteEngine On 
       RewriteCond %{HTTP_HOST} ^https://domain1.com 
       RewriteRule ^/(.*)$ https://www.domain1.com/$1 [L,R=301] 
   
       ErrorLog ${APACHE_LOG_DIR}/error.log 
       CustomLog ${APACHE_LOG_DIR}/access.log combined 
   
       ErrorDocument 404 /404.html 
   
       SSLCertificateFile /etc/letsencrypt/live/domain1.com/cert.pem 
       SSLCertificateKeyFile /etc/letsencrypt/live/domain1.com/privkey.pem 
       Include /etc/letsencrypt/options-ssl-apache.conf 
       SSLCertificateChainFile /etc/letsencrypt/live/domain1.com/chain.pem 
   </VirtualHost> 
   </IfModule> 
   

Когда я пытаюсь зайти на сайт, следующие вещи:

http://test.domain1.com --> https://test.domain1.com FAIL 
    http://domain1.com  --> https://www.domain1.com SUCCESS 
    http://www.domain1.com --> https://www.domain1.com SUCCESS 
    https://domain1.com  --> https://domain1.com  FAIL 
    https://www.domain1.com --> https://www.domain1.com SUCCESS 

Как вы можете видеть, первый и четвертая запись не удалась. Они оба возвращают 404 Not Found моим посетителям, что неприемлемо для меня. Первый даже показывает предупреждение SSL (я не думаю, что LetsEncrypt! Поддерживает подстановочные знаки, поэтому я думаю, что это предупреждение не может быть предотвращено?)

Что вызывает мой тест. не перенаправлять на www.?

Что приводит к тому, что моя четвертая запись заканчивается служением 404?

Теперь я также хочу, чтобы мой второй домен (domain2.com) указывал на этот сервер/файлы. Этот домен размещен в другом месте (я получил его от друга) и использует разные серверы имен. Я не могу просто изменить сервер имен (я думаю?), Потому что у этого второго домена есть связанный с ним почтовый хостинг, который использует серверы имен этого другого провайдера. На мгновение этот домен также имеет собственный веб-сервер (но это уйдет в будущем), размещенное на уровне 000.000.000.002. Сейчас он использует

<meta http-equiv="refresh" content="0; url=https://www.domain1.com" /> 

тег в файле index.html для перенаправления на нужный сервер, в будущем это должно быть сделано в DNS записей, хотя.

Как мне это сделать?

Итак, подведем итог:

1. Я думал CNAME * это всеобъемлющая для всех поддоменов?
2. Что я сделал неправильно в файле виртуальных хостов? Что-то заставляет четвертую переадресацию терпеть неудачу.
3. Как я должен обрабатывать свой второй домен, указывающий на мой первый IP-адрес?
4. Есть ли другой способ подключения HTTPS? (Это также должно быть принудительно применено к виртуальному хосту API). Я слышал о HSTS, должен ли я это реализовать?

Некоторые SEO-тесты также указывали, что мне нужно перенаправление IP для дальнейшего улучшения результатов SEO. Они приводят это в качестве примера:

RewriteCond %{HTTP_HOST} ^000\.000\.000\.001 
    RewriteRule (.*) http://www.domain1.com/$1 [R=301,L] 

Должен ли я также реализовать это для целей SEO? Должен ли я также реализовать это для моего другого IP-адреса?

Так много вопросов ...

Конечно, если у вас есть какие-либо другие предложения, пожалуйста, поделитесь своим мнением!

Answer 1

Много вопросов есть! Давайте попробуем работать через них:

1. Не уверен, что вы просите здесь, а не специалист в синонимах, но думали бы вы должны были бы «* .domain1.com», по крайней мере, вместо того, чтобы просто «* '

2. Для обоих вы не указали явно свои альтернативные имена серверов ни в ServerName, ни в ServerAlias. В этом случае он будет по умолчанию первым сервером, найденным в конфиге. Это api.domain.com один? Если это так, чтобы объяснить 404, поскольку SERVER_NAME (по умолчанию) будет поставляться клиентом, поэтому параметры api.domain1.com:80 будут просто перенаправлять на версию https того, что они отправили (что, как представляется, происходит) , который затем также рассмотрит конфигурацию api.domain1.com:443 и не найдет имя. Вам нужно будет либо добавить альтернативные имена к настройке ServerAlias ​​в вашей основной конфигурации domain1.com, либо перенести эту конфигурацию в первую очередь, чтобы она стала стандартной, а api-only используется, когда имя api.domain1.com явно используется ,

3. Поскольку вы хотите перенаправить это прямо на свой новый сайт, я бы обновил DNS, указав на ваш новый IP-адрес, чтобы сэкономить вам деньги на двух серверах (с точки зрения денег и времени на администрирование). Это можно сделать на существующем DNS-сервере имен, чтобы сохранить электронную почту, хотя, очевидно, было бы лучше консолидироваться на одном. В то же время реализовать надлежащую 301 переадресацию в конфигурации сервера, поскольку мета-перенаправление не так сильно сигнал для поисковых систем, и вы, похоже, заботитесь о SEO.

4. Основной способ перенаправления http на https. HSTS - это прежде всего функция безопасности, которая автоматически перенаправляет http на https до браузер делает запрос. Это полезно, поскольку по умолчанию используется http (например, набрав www.example.com в адресной строке браузера, по умолчанию вы отправите http://www.example.com, а не https://www.example.com), и это может быть перехвачено, чтобы предотвратить обновление до https (что больше трудно перехватить).У него есть некоторые недостатки: не все браузеры поддерживают его, вам нужно посетить веб-сайт хотя бы один раз, чтобы загрузить настройки HSTS (хотя некоторые браузеры позволяют предварительно загружать это), и этот параметр истекает, если сайт не посещается в maxAge (опять же, если предположить, что он не предварительно загружен). Поэтому он не должен использоваться в качестве замены для перенаправления, а скорее как принудительное исполнение для браузеров, поддерживающих HSTS. Об этом сообщается here, если вы хотите узнать больше о HSTS.

Я хотел бы также сказать, у вас есть несколько различных методов перенаправления (АНП: 80 имеет Rewrite, domain1: 80 имеет Redirect, domain1: 443 имеет Rewrite - но с очень ограничительным и неправильным RewriteCond). Лично я предпочитаю использовать один метод, поскольку он менее запутан, но это личное дело (Redirect также немного быстрее, но Rewrite дает вам больше мощности, поэтому я предпочитаю это). Так что, как правило, имеют конфигурации, как это:

<VirtualHost *:80> 
    #This is the first host so is the default. 
    #So although I've specified a ServerName and ServerAlias anything else not specified elsewhere will also end up here. 
    ServerName www.domain1.com 
    ServerAlias domain1.com 

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

    #Redirect everything to https: 
    RewriteEngine on 
    RewriteRule ^(.*)$ https://www.domain1.com$1 [R=301,L] 
</VirtualHost> 
<VirtualHost *:80> 
    ServerName api.domain1.com 

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

    #Redirect everything to https: 
    RewriteEngine on 
    RewriteRule ^(.*)$ https://api.domain1.com$1 [R=301,L] 
</VirtualHost> 

, а затем на 443, я бы это:

<VirtualHost *:443> 
    #This is the first host so is the default. 
    #So although I've specified a ServerName and ServerAlias anything else not specified elsewhere will also end up here. 
    ServerName www.domain1.com 
    ServerAlias domain1.com 

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

    #Redirect everything which is not already on the real www domain name to that: 
    RewriteEngine on 
    RewriteCond %{HTTP_HOST} !www.domain1.com 
    RewriteRule ^(.*)$ https://www.domain1.com$1 [R=301,L] 

    #all your other 443 config for www.domain1.com 

</VirtualHost> 
<VirtualHost *:443> 
    ServerName api.domain1.com 

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

    #all your other 443 config for api.domain1.com 

</VirtualHost> 

Обратите внимание, что я добавил различные файлы журналы для каждого виртуального хоста, так что это более очевидно, какие vhost поражается.

Обратите внимание, что я перенаправляю все, что не является www.domain1.com, а не вашей версией, которая перенаправляется только в том случае, если люди набрали домен1.com (и который я не уверен, будет использоваться в качестве подозреваемого api.domain1.com config пришел первым).

Это также позаботится обо всех, кто обращается к вашему сайту по IP-адресу или любому другому имени, поскольку он всегда будет перенаправлен на ваше настоящее имя сервера www.domain1.com. Это легко для HTTP-запросов, но для запросов https они действительно могут получить ошибку сертификата, если ваш сертификат не включает имя сервера.

LetsEncrypt не поддерживает подстановочные знаки, но допускает несколько имен в сертификате, поэтому вы можете легко получить сертификат для domain1.com и www.domain1.com, и вы должны, поскольку это обычно считается лучшей практикой. Вы также можете добавить любые другие домены, которые, по вашему мнению, могут быть использованы. Для вас домен api.domain1.com вы также можете добавить к этому же сертификату или получить отдельный сертификат для этого, так как у вас есть отдельная конфигурация для этого (ваша конфигурация выше не ясна, для чего вы это делаете, поскольку она выглядит так же config, но не уверен, что это опечатка или нет).

В целях SEO лучше всего обслуживать только ваш сайт под одним URL-адресом и использовать перенаправления для обеспечения того, чтобы этот URL-адрес и выше были выполнены. Это делается для того, чтобы Google не думал, что у вас есть дублирующийся контент, если вы используете тот же контент по адресу www.domain1.com/page1.html и https://www.domain1.com/page1.html и https://domain1.com/page1.html и http://000.000.000.001/page1.html ... и т. Д.

Много покрыто там, но, надеюсь, указывает вам в правильном направлении.