Простой способ просмотра сайта с IP-адресом, отличным от имени хоста?

Question

Некоторый фон - WordPress действительно раздражает с точки зрения того, с какого имени хоста вы к нему обращаетесь, что делает создание сред тестирования довольно болезненным (то есть я мог бы создать поддомен для промежуточного размещения, y.x.com , но тогда WordPress установил бы все ссылки в базе данных как оттуда, а не от x.com , где они будут, как только я сделаю замену DNS). Чтобы обойти это, я установил псевдоним в моем файле /etc /hosts, поэтому мне не нужно постоянно менять доменное имя в настройках WP.

Другими словами: сейчас у меня есть живой сайт, работающий на IP x и hostname x.com . Я хочу оставить работающий сайт работающим и настроить промежуточный компьютер на IP y , доступ к которому осуществляется через имя хоста x.com , используя запись в вышеупомянутом /etc/hosts .

Мой вопрос: как показать клиенту промежуточную машину, не заставляя их редактировать файл /etc /hosts? Есть ли служба онлайн, которая устанавливает iframe и показывает вам определенный IP-адрес в качестве определенного имени хоста?

Спасибо!

Изменить: я не спрашиваю, как настроить мои записи DNS; они хороши на данный момент. Я могу перейти к промежуточному компьютеру, просто введя его IP-адрес в адресную строку, и WordPress загружается и все отлично, за исключением того, что все ссылки на x.com , и щелкнув по ним, я перехожу на рабочий / рабочий сайт. Я могу исправить это, поместив запись в файл hosts моего локального компьютера (т.е. /etc/hosts), который переопределяет общедоступные записи DNS на действующий сайт и вместо этого показывает мне промежуточную машину. По сути, я хочу, чтобы это было легко сделать для моего клиента, то есть без необходимости редактировать файл hosts .

Answer 1

Другой способ - это обычный прокси-сервер (например, Squid) и отредактированный файл /etc/hosts на прокси-сервере.

Когда вы используете прокси-сервер HTTP, браузер клиента не выполняет поиск DNS для x.com, но подключается к прокси-серверу и сообщает ему о подключении к x.com. Поскольку вы согнули x.com к другому IP-адресу на прокси-сервере, вы получите результаты от промежуточного сервера.

Answer 2

вы не можете привязать одно и то же имя хоста к разным IP-адресам. Либо вам нужно отредактировать свои записи DNS, чтобы указать домен для промежуточной машины, либо вам нужно внести изменения в разрешение локального хоста через файл hosts.

Кроме того, вы можете добавить переменную проверки / условия через PHP или другой язык, на котором работает ваш сайт, если он есть, откроется ваш сайт на промежуточной машине, например, http://examplesite.com/?staging=true

Answer 3

Подключите x.com/staging к другому серверу

Предполагая, что вы работаете на Apache, проксирование может помочь. Запуск обратного прокси в Apache предполагает, что может сработать следующее, но я не проверял это:

ProxyPreserveHost on
ProxyPass /staging/ http://y.y.y.y/
ProxyHTMLURLMap http://y.y.y.y /staging

<Location /staging/>
    ProxyPassReverse /
    ProxyHTMLEnable On
    ProxyHTMLURLMap / /staging/
    # We need to peek into the HTML, so ensure we don't get gzip'd content:
    RequestHeader unset Accept-Encoding
</Location>

Выше виртуальная папка /staging карта отображает все с http://x.com/staging/ на / на другой IP-адрес. Чтобы по-прежнему использовать x.com в качестве хоста, я добавил ProxyPreserveHost.

Все это потребует конечной косой черты; некоторое стандартное переписывание может добавить это при необходимости:

# Add trailing slash if omitted
RewriteRule ^staging$ /staging/ [R=302,L]

Избегайте совместного использования файлов cookie: используйте выделенный домен

Однако, чтобы избежать очень неприятных проблем с сеансовыми cookie-файлами, я бы предпочел выделенный домен (желательно даже не какой-либо поддомен x.com). Для этого удалите все ссылки на staging выше. И все же, чтобы отправить ожидаемое доменное имя, я предполагаю, что можно добавить еще:

RequestHeader set Host x.com

При использовании такого выделенного домена Apache также не придется переписывать относительные URL-адреса, такие как /some/page в /staging/some/page . Однако это может означать, что вы не заметите сбоев в переписывании абсолютных URL-адресов (особенно это возможно при использовании JavaScript). Подобно тому, как ошибка перезаписи http://x.com/some/page обратно на http://client.mycompany.com/some/page может остаться незамеченной, если такой же URL-адрес существует на рабочем сервере, и браузер извлекает его напрямую , Это может быть преимуществом или катастрофой, если вы по-прежнему подключены к производственному серверу и думаете , что меняете содержимое на промежуточном сервере ...

Использование .htaccess

Просто для потомков ранее я подумал, что можно также использовать что-то вроде следующего в файле .htaccess :

# Does NOT work (for me). On the target server, this gets me:
#   HTTP_HOST = y.y.y.y            - from the proxy request? Expected x.com
#   HTTP_X_FORWARDED_HOST = x.com  - from Host
#   HTTP_X_MY_DUMMY = x.com        - from X-My-Dummy, as expected

RewriteEngine On
RequestHeader set Host x.com 
RequestHeader set X-My-Dummy x.com
RewriteRule ^(.*) http://y.y.y.y/$1 [L,P] 
ProxyPassReverse / http://y.y.y.y/

Однако ProxyPassReverse , по-видимому, не разрешен в .htaccess . И некоторые базовые тесты показывают, что прокси-сервер [P] также всегда добавляет свой собственный заголовок Host и переводит мой Host в X-Forwarded-Host . Это вполне может быть связано с виртуальным виртуальным хостингом, который я использовал для быстрого тестирования. Но ProxyPreserveHost нельзя использовать в .htaccess .

См. Документацию Apache по mod_proxy, mod_headers и mod_rewrite .