Apache HTTP Server — Поддержка виртуальных хостов на основе имен Этот документ описывает,когда и как использовать виртуальные хосты,основанные на именах.
Этот документ описывает,когда и как использовать виртуальные хосты,основанные на именах.
Виртуальные хозяева,основанные на именах,в сравнении с виртуальными хозяевами,основанными на IP.
Виртуальные хосты на основе IP используют IP-адрес соединения, чтобы определить правильный виртуальный хост для обслуживания. Поэтому вам нужно иметь отдельный IP-адрес для каждого хоста.
При использовании виртуального хостинга,основанного на именах,сервер полагается на клиента,который сообщает имя хоста как часть HTTP-заголовков.Используя эту технику,многие различные хосты могут иметь один и тот же IP-адрес.
Виртуальный хостинг на основе имен обычно проще,так как вам нужно только настроить DNS-сервер для сопоставления каждого имени хоста с правильным IP-адресом,а затем настроить HTTP-сервер Apache на распознавание различных имен хостов. Виртуальный хостинг на основе имен также облегчает спрос на скудные IP-адреса.Поэтому вам следует использовать виртуальный хостинг на основе имен,если только вы не используете оборудование,которое явно требует хостинг на основе IP.Исторические причины виртуального хостинга на основе IP-технологий,основанного на поддержке клиентов,больше не применимы к веб-серверу общего назначения.
Виртуальный хостинг на основе имен построен на алгоритме выбора виртуального хоста на основе IP,что означает,что поиск правильного имени сервера происходит только между виртуальными хостами,которые имеют лучший IP-адрес.
Как сервер выбирает правильный виртуальный хост на основе имени.
Важно понимать,что первым шагом в разрешении виртуальных хостов на основе имен является разрешение на основе IP.Разрешение виртуальных хостов на основе имен выбирает только наиболее подходящий виртуальный хост на основе имен после сужения списка кандидатов до наилучшего соответствия IP-адресам.Использование подстановочного знака (*)для IP адреса во всех директивах VirtualHost делает эту IP-ориентированную привязку неактуальной.
Когда поступает запрос, сервер находит лучший (наиболее конкретный) соответствующий аргумент <VirtualHost>
на основе IP-адреса и порта, используемых запросом. Если существует более одного виртуального хоста, содержащего эту наиболее подходящую комбинацию адреса и порта, Apache дополнительно сравнит директивы ServerName
и ServerAlias
с именем сервера, представленным в запросе.
Если вы опустите директиву ServerName
для любого виртуального хоста на основе имени, сервер по умолчанию будет использовать полное доменное имя (FQDN), полученное из системного имени хоста. Это неявно заданное имя сервера может привести к нелогичному сопоставлению виртуальных хостов и не рекомендуется.
Фрост по умолчанию,основанный на имени для комбинации IP и порта.
Если в наборе виртуальных хостов, содержащем наиболее конкретную комбинацию IP-адресов и портов, не найдено подходящего ServerName или ServerAlias, то будет указан первый виртуальный хост , который будет использоваться.
Использование виртуальных хозяев на основе имен
Related Modules | Related Directives |
---|---|
|
|
Первый шаг — создать блок <VirtualHost>
для каждого отдельного хоста, который вы хотите обслуживать. Внутри каждого блока <VirtualHost>
вам потребуется как минимум директива ServerName
, чтобы указать, какой хост обслуживается, и директива DocumentRoot
, чтобы показать, где в файловой системе находится контент для этого хоста.
Главный хозяин уходит
Любой запрос, не соответствующий существующему <VirtualHost>
, обрабатывается глобальной конфигурацией сервера, независимо от имени хоста или ServerName.
Когда вы добавляете виртуальный хост на основе имени к существующему серверу, а аргументы виртуального хоста соответствуют ранее существовавшим комбинациям IP-адреса и порта, запросы теперь будут обрабатываться явным виртуальным хостом.
ServerName
, совпадающим с именем базового сервера. Новые домены с тем же интерфейсом и портом, но требующие отдельных конфигураций, затем могут быть добавлены как последующие (не используемые по умолчанию) виртуальные хосты.ServerName inheritance
Лучше всегда явно указывать ServerName
в каждом виртуальном хосте на основе имени.
Если VirtualHost
не указывает ServerName
, имя сервера будет унаследовано от базовой конфигурации сервера. Если глобальное имя сервера не указано, оно обнаруживается при запуске посредством обратного разрешения DNS первого адреса прослушивания. В любом случае это унаследованное имя сервера будет влиять на разрешение виртуального хоста на основе имени, поэтому лучше всегда явно указывать ServerName ServerName
каждом виртуальном хосте на основе имени.
Например, предположим, что вы обслуживаете домен www. example.com
и хотите добавить виртуальный хост other.example.com
, который указывает на тот же IP-адрес. Затем вы просто добавляете следующее в httpd.conf
:
<VirtualHost *:80> # Этот первый в списке виртуальный хост также используется по умолчанию для *: 80 ServerName www.example.com ServerAlias example.com DocumentRoot "/www/domain" </VirtualHost> <VirtualHost *:80> ServerName other.example.com DocumentRoot "/www/otherdomain" </VirtualHost>
В качестве альтернативы вы можете указать явный IP-адрес вместо
в директивах <VirtualHost>
. Например, вы можете захотеть сделать это, чтобы запустить некоторые виртуальные хосты на основе имени на одном IP-адресе и либо на основе IP, либо другой набор виртуальных хостов на основе имени на другом адресе.
Многие серверы хотят быть доступными более чем по одному имени. Это возможно с помощью директивы ServerAlias
, помещенной в раздел <VirtualHost>
. Например, в первом блоке <VirtualHost>
выше директива ServerAlias
указывает, что перечисленные имена — это другие имена, которые люди могут использовать для просмотра того же веб-сайта:
ServerAlias example.com *.example.com
затем запросы для всех хостов в домене example.com
будут обслуживаться виртуальным хостом www.example.com
. Подстановочные знаки *
и ?
можно использовать для сопоставления имен. Конечно, вы не можете просто придумать имена и поместить их в ServerName
или ServerAlias
. Сначала вы должны правильно настроить DNS-сервер для сопоставления этих имен с IP-адресом, связанным с вашим сервером.
Виртуальные хосты на основе имен для наиболее подходящего набора <virtualhost>
обрабатываются в том порядке, в котором они появляются в конфигурации. Используется первое совпадающее ServerName
или ServerAlias
без другого приоритета для подстановочных знаков (и для имени_сервера по сравнению с псевдонимом_сервера).
Полный список имен в директиве VirtualHost
обрабатывается так же, как (без подстановочных знаков) ServerAlias
.
Наконец, вы можете точно настроить конфигурацию виртуальных хостов, поместив другие директивы в контейнеры
. Большинство директив можно поместить в эти контейнеры, и тогда они изменят конфигурацию только соответствующего виртуального хоста. Чтобы узнать, разрешена ли конкретная директива, проверьте контекст директивы. Директивы конфигурации, установленные в контексте основного сервера (вне любого контейнера <VirtualHost>
), будут использоваться только в том случае, если они не переопределяются настройками виртуального хоста.
Apache HTTP Server 2.4
-
Пределы описания файлов
- Документация по виртуальному хосту Apache
-
Поддержка виртуальных узлов на базе IP-технологий Apache
-
Динамически конфигурируемый массовый виртуальный хостинг
- 1
- …
287- 288
- 289
- 290
- 291
Директивы конфигурации веб-сервера Apache | Сетевые технологии
Учебные программы » Сетевые технологии » Дополнительные материалы » Директивы конфигурации веб-сервера Apache
Приведены основные (не все) директивы управления работой веб-сервера Apache2, полное описание доступно на сайте http://httpd. apache.org/.
- ServerType
- Для этой директивы значением по умолчанию является ServerType standalone. Серверы, работающие в автономном режиме (standalone), запускаются из загрузочных сценариев при запуске системы. Такая установка рекомендуется для улучшения производительности.
В качестве альтернативы режиму standalone можно воспользоваться режимом inetd, который обеспечивается демоном inetd. - Port
- В этой директиве задается номер сетевого порта, на котором будет работать ваш сервер, если он запущен в автономном режиме (если используется inetd, то номер порта следует задать в файле /etc/services). Значением по умолчанию для этой директивы является
Port 80
. Этот порт является стандартным для протокола HTTP (см. порты сетевых сервисов) и рекомендуется для использования на основном сервере вашего Web-узла. - HostnameLookups
- Директива HostnameLookups указывает, записывается ли в журнальный файл доменное имя узла или только его IP-адрес.
HostnameLookups off
. - User и Group
- Эти параметры задают действительные идентификаторы пользователя и группы, которые присваиваются серверу, работающему в автономном режиме. По умолчанию в качестве имени пользователя принимается nobody, что является превосходным выбором с точки зрения защиты информации. Ни в коем случае нельзя запускать сервер с привилегиями суперпользователя (root).
В качестве идентификатора группы следует использовать идентификатор какой-нибудь нейтральной группы, имеющейся в системе. Часто используется группа news. Либо можно специально создать для сервера новую группу. Если указанные пользователь и группа не существуют в системе, сервер не будет работать. - ServerAdmin [email protected]
- Официальный электронный адрес вебмастера вашего Web-узла.
- ServerRoot
- В этой директиве задается базовый каталог, в котором будет установлено программное обеспечение HTTP-сервера Apache.
- BindAddress
- Эта директива используется для компьютеров, имеющих несколько сетевых интерфейсов. С ее помощью можно устанавливать прослушивание сервером еще какого-то из IP-адресов компьютера. По умолчанию эта директива закомментирована, и сервер производит прослушивание всех адресов компьютера.
- ErrorLog /usr/local/apache/logs/error_log и CustomLog /usr/local/apache/logs/access_log common
- При помощи этих двух директив задается путь к log-файлам, в которых регистрируются ошибки и попытки доступа к серверу соответственно. В файле, указанном в директиве
- ServerName
- Директива ServerName позволяет задать имя хоста, возвращаемое клиенту. Имя, которое вы определяете здесь, должно быть зарегистрированным доменным именем вашего хоста. Если сервер не имеет зарегистрированного имени, вы можете указать здесь его адрес IP, но вам придется обращаться к нему по адресу (например, http://192.168.0.1/) и это может сильно осложнить переадресацию ресурсов.
- Timeout
- Это промежуток времени в секундах (по умолчанию &mdash 300), в течение которого сервер ждет продолжения недополученного запроса или продолжает попытки возобновления приостановленной передачи ответа.
- KeepAlive
- KeepAlive является свойством протокола HTTP 1.1, позволяющим ускорить обработку запросов путем удержания соединения и выполнения нескольких запросов. В HTTP 1.0 передача Web-страницы с четырьмя встроенными изображениями потребовала бы пять отдельных соединений, а с использованием KeepAlive все последовательные запросы производятся в рамках одного соединения. По умолчанию &mdsh;
KeepAlive On
- MaxClients
- Директива MaxClients устанавливает максимальное число копий сервера, которые могут выполняться одновременно. Когда достигается этот предел (по умолчанию — 150), новые запросы получают отказ. Если вам не хочется отказывать пользователям, не устанавливайте слишком маленькое значение. Медленный ответ все-таки лучше, чем отказ от обслуживания.
- Listen
- Эта директива позволяет привязать Apache к конкретному адресу IP, и/или порту, в дополнение к порту, определенному по умолчанию.
- DocumentRoot
- В этой директиве задается каталог, из которого берутся передаваемые клиентам документы. Можно предоставлять клиентам и файлы, находящиеся в других каталогах, — для этого используются символьные ссылки.
- UserDir public_html
- Название каталога, которое прибавляется к именам пользовательских домашних каталогов при получении запроса ~user (напр.»http://www.example.com/~user»). Если не требуется использовать возможность пользовательских каталогов, следует указать
UserDir DISABLED
. - DirectoryIndex index.html
- Эта директива позволяет задать название документа, возвращаемого по запросу, который не содержит в строке URI названия документа. Если вы указываете несколько имен, разделяйте их пробелами. Пример:
DirectoryIndex index.html index.php index.htm default.html
Сервер будет искать перечисленные файлы в соответствующем порядке. - IndexOptions FancyIndexing
- При получении запроса на передачу каталога сервер Apache:
- находит файл, указанный в директиве DirectoryIndex (если таковой существует), и передает его клиенту;
- если файл DirectoryIndex не существует, передает клиенту оглавление каталога.
Если выбрана опция Fancylndexing, то в оглавлении используются значки и описания файлов. Если эта опция отключена, сервер представляет оглавление в более простом виде. - AccessFileName
- Имя файла, который сервер ищет в каждом каталоге для определения прав доступа. По умолчанию —
.htaccess
(с точкой в начале). - DefaultType
- Директива DefaultType определяет MIME-тип, который будет использоваться для какого-либо документа, если сервер не сможет определить его по иным признакам, например по расширению. По умолчанию значение DefaultType — text/plain. Если большая часть файлов бинарники (программы, картинки и т.п.) стоит изменить значение на «application/octet-stream», чтобы предотвратить попытку браузера показать содержимое двоичного файла.
- AddEncoding x-compress Z и AddEncoding x-gzip gz tgz
- Эти директивы позволяют сжимать отдаваемые документы перед отправкой, что экономит трафик и ускоряет загрузку. Браузеры, поддерживающие эту возможность (Mozilla, SeaMonkey, FireFox), распаковывают полученные файлы «на лету».
- Redirect
- Директива Redirect позволяет переадресовать запрос к ранее существовавшему в именном пространстве сервера документу на его новый адрес. Пример:
Redirect http://example.com/old-location/test.html http://example.com/new-location/test.html
- Alias
- Директивы Alias дают возможность предоставлять доступ к документам, находящимся не только в корневом каталоге сервера (DocumentRoot) и его подкаталогах, но и в других каталогах. По умолчанию в директиве Alias задан только один псевдоним — /icons, используемый директивами Addlcon и AddIconByType. Обратите внимание, что если вы включаете завершающий слэш в «псевдоним», то сервер потребует его присутствия и в URL. Пример:
Alias /icons/ "/usr/local/apache/icons/"
- ScriptAlias
- Директива указывает каталог, который содержит серверные скрипты. Свойства ScriptAlias-ов такие же, как
и у просто Alias-ов, кроме того, что документы в заданном директивой каталоге считаются приложениями и выполняются на сервере, а не отправляются клиенту. К директиве ScriptAlias применяются те же правила в отношении завершающего «/», что и к Alias.Разрешается добавлять неограниченное число директив
ScriptAlias. Примеры:
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
ScriptAlias /user1/ "/usr/home/user1/public_html/cgi-bin/" - AddType
- Директива AddType позволяет добавить описания типов файлов (помимо MIME-types) и порядок их обработки. Примеры:
#файлы с расширением .shtml должны обрабатываться как html файлы AddType text/html .shtml #файлы с расширением .php должны запускаться как php файлы AddType application/x-httpd-php .php #файлы с расширением .html должны запускаться и как php файлы AddType application/x-httpd-php .html #файлы с расширением .pl должны запускаться как cgi файлы AddType application/x-httpd-cgi .pl
- AddHandler
- Сервер Apache имеет возможности модификации файлов определенных типов перед отправкой их пользователю. Директива AddHandler ставит в соответствие расширению файла определенное действие. Например:
AddHandler server-parsed .shtml
включает поддержку технологии SSI (Server-side Includes) и Apache выполняет разбор файлов .shtm на предмет поиска в них директив SSI. Если изменить параметр так:AddHandler server-parsed .html
то Apache будет парсить и .html-файлы.
Функция, указанная в директиве AddHandler, не обязательно должна являться встроенной функцией сервера. ДирективаAction
может ставить в соответствие функции из AddHandler сценарий CGI. Например, следующие строки в файле srm.conf сначала указывают серверу, что функция foo поставлена в соответствие сценарию bar.pl, который всякий раз запускается при обращении к файлам с расширением .ext:Action foo /user/cgi-bin/bar.pl AddHandler foo .ext
- ErrorDocument
- Эта директива позволяет переопределить сообщения об ошибках, сопоставив в соответствие кодам ошибок HTTP-сервера текстовые сообщения и/или адреса URL на том же сервере. Например:
ErrorDocument 404 "Этого файла нет, не было и не будет на сервере!"
- Options
- Эта директива перечисляет список опций, применяемых к указанному каталогу. Опции могут иметь значения
«None», «All» или любую комбинацию из «Indexes», «Includes», «FollowSymLinks», «ExecCGI» или «MultiViews». Например, такая конфигурация определяет порядок отображения индексной страницы, разрешает серверные включения (SSI) и переход по символьным ссылкам:
Options Indexes Includes FollowSymLinks
- AllowOverride
- С параметром
none
блокирует использование файла .htaccess, с параметромall
— разрешает перекрывать дефолные настройки директивами из .htaccess. - Order
- Директива, вместе с директивами
Allow
иDeny
, определяющая порядок обращения к ресурсам в соответствии с правами доступа. Пример:Order allow,deny Allow from all
Чтобы подсказать браузеру, какие файлы ему предстоит обрабатывать, сервер формирует определенный код типа документа, основываясь на спецификации MIME — Multipurpose Internet Mail Extensions — многоцелевые почтовые расширения Internet) и передает этот код в заголовке HTTP-протокола.
CC-BY-CA Анатольев А.Г., 31.01.2012
Разделы дисциплины
Методические материалы
Конспект лекций
Лабораторный практикум
Задания на самостоятельную подготовку
Дополнительные материалы
Материалы раздела
Как купить Ripple (XRP) по карте Visa или MasterCard
Краткий обзор симуляторов сети
Что такое «облачные» вычисления?
Протоколы электронной почты
Сети и системы слаботочного типа: обслуживание
Быстрая установка PostgreSQL
Сервис RRAS. Маршрутизация и удаленный доступ
Сетевые устройства
AON – сети будущего
Список протоколов по уровням модели OSI
Защита информации
Установка TomCat в OpenSuSE
Тонкие клиенты — реальная альтернатива ПК или маркетинговый ход?
Бездисковые рабочие станции
Wireshark Network Analyzer
Система прав доступа и безопасность
Система доменных имен
Служба WINS
Технология Wi-Fi
Насколько опасен вирус
Коды ответа сервера
Настройка сетевого оборудования
Перекодировка таблиц MySQL
Директивы конфигурации веб-сервера Apache
Связанные темы
Установка и настройка веб-сервера Apache
Серверы приложений. Установка и настройка Tomcat
Поддержка виртуального хоста на основе имени — Apache HTTP Server версии 2.4
Поддержка виртуального хоста на основе имени — Apache HTTP Server версии 2.4Apache HTTP Server версии 2.4
Apache > HTTP-сервер > Документация > Версия 2. 4 > Виртуальные хосты
Доступные языки: de | ru | фр | я | ко | tr
В этом документе описывается, когда и как использовать виртуальные хосты на основе имени.
- Виртуальные хосты на основе имени и на основе IP
- Как сервер выбирает правильный виртуальный хост на основе имени
- Использование виртуальных хостов на основе имен
См. также
- Поддержка виртуальных хостов на основе IP
- Подробное обсуждение сопоставления виртуальных хостов
- Динамически настроенный массовый виртуальный хостинг
- Примеры виртуальных хостов для общих настроек
- Комментарии 9 0017
Виртуальные хосты на базе IP использовать IP-адрес подключения к определить правильный виртуальный хост для обслуживания. Поэтому вам нужно иметь отдельный IP-адрес для каждого хоста.
При виртуальном хостинге на основе имени сервер полагается на клиента для сообщить имя хоста как часть заголовков HTTP. Используя эту технику, один и тот же IP-адрес может использоваться многими разными хостами.
Виртуальный хостинг на основе имени обычно проще, так как вам нужно только настройте свой DNS-сервер для сопоставления каждого имени хоста с правильным IP-адрес, а затем настройте HTTP-сервер Apache для распознавания разные имена хостов. Виртуальный хостинг на основе имени также упрощает спрос на дефицитные IP-адреса. Поэтому вы должны использовать виртуальный хостинг на основе имени, если вы не используете оборудование который явно требует хостинга на основе IP. Исторические причины Виртуальный хостинг на основе IP, основанный на клиентской поддержке, больше не применимо к веб-серверу общего назначения.
Виртуальный хостинг на основе имени строится на основе виртуального хоста на основе IP алгоритм выбора, означающий, что ищет правильное имя сервера происходят только между виртуальными хостами, которые имеют лучший IP-адрес.
Важно понимать, что первый шаг к созданию виртуальных разрешение хоста — это разрешение на основе IP. Виртуальный хост на основе имени разрешение выбирает только наиболее подходящий виртуальный хост на основе имени после сужения кандидатов до лучшего совпадения на основе IP. Использование подстановочного знака (*) для IP-адреса во всех директивах VirtualHost делает это Отображение на основе IP не имеет значения.
При поступлении запроса сервер найдет наилучшее (наиболее конкретное) соответствие
аргумент на основе
IP-адрес и порт, используемые запросом. Если имеется более одного виртуального хоста
содержащий эту комбинацию адреса наилучшего совпадения и порта, Apache
сравните директивы ServerName
и ServerAlias
с именем сервера
присутствует в запросе.
Если опустить ServerName
директивы с любого виртуального хоста на основе имени, сервер по умолчанию
на полное доменное имя (FQDN), полученное из системного имени хоста.
Это неявно заданное имя сервера может привести к нелогичному виртуальному хосту. соответствует и не рекомендуется.
Виртуальный хост по умолчанию на основе имени для комбинации IP-адреса и порта
Если в наборе виртуальные хосты, содержащие наиболее конкретный соответствующий IP-адрес и порт комбинация, затем первый указанный виртуальный хост , который спички, которые будут использоваться.
Первым шагом является создание блока
для
каждый отдельный хост, который вы хотели бы обслуживать. Внутри каждого
вам понадобится как минимум ServerName
директива для назначения
какой хост обслуживается и DocumentRoot
директива, чтобы показать, где в файловой системе содержимое для этого хоста
жизни.
Главный хост уходит
Любой запрос, не соответствующий существующему
, обрабатывается глобальным
конфигурации сервера, независимо от имени хоста или имени сервера.
При добавлении виртуального хоста на основе имени к существующему серверу и
аргументы виртуального хоста соответствуют ранее существовавшим комбинациям IP и портов,
запросы теперь будут обрабатываться явным виртуальным хостом. В этом случае,
обычно целесообразно создать виртуальный хост по умолчанию
с ServerName
совпадает с именем
базовый сервер. Новые домены на том же интерфейсе и порту, но
требующие отдельных конфигураций, затем могут быть добавлены как последующие (не по умолчанию)
виртуальные хосты.
Наследование ServerName
Лучше всего всегда явно указывать ServerName
в каждом виртуальном хосте на основе имени.
Если VirtualHost
не указывает
a ServerName
, имя сервера будет
наследуется от базовой конфигурации сервера. Если имя сервера не было
указывается глобально, один обнаруживается при запуске через обратное разрешение DNS
первого адреса прослушивания. В любом случае это унаследованное имя сервера
будет влиять на разрешение виртуального хоста на основе имени, поэтому лучше всегда
явно указать ServerName
в каждом
виртуальный хост на основе имени.
Например, предположим, что вы обслуживаете домен www.example.com
и вы хотите добавить виртуальный хост other.example.com
, что указывает на тот же IP-адрес.
Затем вы просто добавляете в httpd.conf
следующее:
# Этот первый виртуальный хост также используется по умолчанию для *:80 Имя сервера www.example.com Псевдоним сервера example.com DocumentRoot "/www/домен" <Виртуальный хост *:80> Имя_сервера other.example.com DocumentRoot "/www/otherdomain"
Вы также можете указать явный IP-адрес вместо *
в директивах
. Например, вы можете захотеть сделать это
чтобы запустить несколько виртуальных хостов на основе имени на одном IP-адресе, и либо
На основе IP или другой набор виртуальных хостов на основе имени по другому адресу.
Многие серверы хотят быть доступны более чем по одному имени. Это
возможно с ServerAlias
директива, помещенная внутри Раздел
. Например, в первом блоке
выше, Директива ServerAlias
указывает, что
перечисленные имена — это другие имена, которые люди могут использовать, чтобы увидеть то же самое
веб-сайт:
ServerAlias example.com *.example.com
, то запросы для всех хостов в домене example.com
будут
обслуживаться виртуальным хостом www.example.com
. Подстановочный знак
символов *
и ?
можно использовать для сопоставления имен.
Конечно, вы не можете просто придумать имена и поместить их в ServerName
или ServerAlias
. Вы должны
сначала правильно настройте DNS-сервер для сопоставления этих имен с IP-адресом
адрес, связанный с вашим сервером.
Виртуальные хосты на основе имен для наиболее подходящего набора из
s обработаны
в том порядке, в котором они указаны в конфигурации. Первое совпадение ServerName
или ServerAlias
используется без другого приоритета для подстановочных знаков
(ни для ServerName против ServerAlias).
Полный список имен в VirtualHost
директива обрабатывается так же, как (без подстановочного знака) Псевдоним сервера
.
Наконец-то можно точно настроить конфигурацию виртуальных хостов
путем размещения других директив внутри контейнеров
. Большинство директив могут быть
помещается в эти контейнеры и затем изменит конфигурацию только
соответствующий виртуальный хост. Чтобы узнать, разрешена ли конкретная директива,
проверить контекст
директива. Директивы конфигурации, установленные в основной контекст сервера (вне любого
контейнер) будут использоваться только в том случае, если они не переопределены виртуальным хостом.
настройки.
Обратите внимание:
Это не раздел вопросов и ответов. Комментарии, размещенные здесь, должны указывать на предложения по улучшению документации или сервера и могут быть удалены нашими модераторами, если они либо реализованы, либо считаются недействительными/не по теме. Вопросы о том, как управлять HTTP-сервером Apache, следует направлять либо на наш IRC-канал #httpd, на Libera.chat, либо в наши списки рассылки.
apache 2.2 — Разница между ServerName и ServerAlias
Одно ключевое различие, которое я обнаружил экспериментально (исходя из необходимости), заключается в том, что при использовании поддоменов с подстановочными знаками (например, «*.mycompany.com» и «*.mycompany. net»), то подстановочный знак должен быть указан как ServerAlias, а не ServerName.
Я не пробовал это с не-SSL, но с SSL это было так (для меня). Я остановился на конфигурации:
Listen *:8443 NameVirtualHost *:8443 SSLStrictSNIVHostОтметить <Виртуальный хост *:8443> Имя сервера mycompany.com Псевдоним сервера *.mycompany.com . .. <Виртуальный хост *:8443> имя_сервера mycompany.net Псевдоним сервера *.mycompany.net ...
При использовании «ServerName *.mycompany.net» всегда использовался первый виртуальный хост. Это был не только сертификат, но и переписываемая логика.
Вполне возможно, что это происходит только с SSL, так как происходит целая куча других вещей — как указано в SSL с виртуальными хостами, использующими SNI и многими потоками ServerFault. Следуя всем советам в них, это был последний аспект, царапающий голову.
Я зашел в эту ветку, чтобы попытаться самому понять, почему была разница, и признаться, я приближаюсь, но не совсем понимаю.
В моем случае ServerName, кажется, делает немного меньше (не обнаруживается при поиске виртуального хоста), а не больше.
Запуск «apacectl -S | httpd -S» в соответствии с советом Иана дает:
подстановочный знак NameVirtualHosts и серверы _default_: *:8443 — это NameVirtualHost сервер по умолчанию mycompany. com (/etc/httpd/conf/httpd.conf:1100) порт 8443 namevhost mycompany.com (/etc/httpd/conf/httpd.conf:1100) дикий псевдоним *.mycompany.com порт 8443 namevhost mycompany.net (/etc/httpd/conf/httpd.conf:1164) дикий псевдоним *.mycompany.net
Редактировать: (добавление ServerName с подстановочным знаком для полноты)
подстановочный знак NameVirtualHosts и серверы _default_: *:8443 — это NameVirtualHost сервер по умолчанию *.mycompany.com (/etc/httpd/conf/httpd.conf:1040) порт 8443 namevhost *.mycompany.com (/etc/httpd/conf/httpd.conf:1040) порт 8443 namevhost *.mycompany.net (/etc/httpd/conf/httpd.conf:1105)
Примечание: слово «дикий» в строке псевдонима в первом случае (с использованием ServerAlias) исходит от apache и не отображается во втором (с использованием ServerName) — я подозреваю, что это важно.
Кроме того, если я удалю «ServerName» из второго виртуального хоста и просто использую псевдоним, следуя совету «должно быть только одно имя сервера», то запрос немного теряется — похоже, он автоматически перенаправляется на «https://test.