Servername apache: Apache — HTTP Apache 2.2 | Дропшиппинг

Содержание

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
`core`	`DocumentRoot` `ServerAlias` `ServerName` `<VirtualHost>`

Первый шаг — создать блок <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> . Большинство директив можно поместить в эти контейнеры, и тогда они изменят конфигурацию только соответствующего виртуального хоста. Чтобы узнать, разрешена ли конкретная директива, проверьте контекст директивы. Директивы конфигурации, установленные в контексте основного сервера (вне любого контейнера <VirtualHost> ), будут использоваться только в том случае, если они не переопределяются настройками виртуального хоста.

Apache HTTP Server 2.4

Пределы описания файлов
Документация по виртуальному хосту Apache
Поддержка виртуальных узлов на базе IP-технологий Apache
Динамически конфигурируемый массовый виртуальный хостинг

Директивы конфигурации веб-сервера 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 позволит уменьшить нагрузку на сервер. Это делается простым изменением строки на 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-файлам, в которых регистрируются ошибки и попытки доступа к серверу соответственно. В файле, указанном в директиве ErrorLog, сервер сохраняет сообщения диагностики, включая сообщения об ошибках, выдаваемые сценариями CGI. В файле, указанном в директиве CustomLog, сервер сохраняет все запросы клиентов. Если включена описанная выше опция HostnameLookups, то вместе с запросами регистрируются имена компьютеров.

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 (с точкой в начале).

Чтобы подсказать браузеру, какие файлы ему предстоит обрабатывать, сервер формирует определенный код типа документа, основываясь на спецификации MIME — Multipurpose Internet Mail Extensions — многоцелевые почтовые расширения Internet) и передает этот код в заголовке HTTP-протокола.

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

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.4

Apache > HTTP-сервер > Документация > Версия 2. 4 > Виртуальные хосты

Доступные языки: de | ru | фр | я | ко | tr

В этом документе описывается, когда и как использовать виртуальные хосты на основе имени.

Виртуальные хосты на основе имени и на основе IP
Как сервер выбирает правильный виртуальный хост на основе имени
Использование виртуальных хостов на основе имен

См. также

Поддержка виртуальных хостов на основе IP
Подробное обсуждение сопоставления виртуальных хостов
Динамически настроенный массовый виртуальный хостинг
Примеры виртуальных хостов для общих настроек
Комментарии

Виртуальные хосты на базе 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.