это просто настройки днс сервера
к веб серверу это отношение имеет посредственное.
Вам нужно установтиь веб сервер на вашу вм
самый прсотой вариант это сделать посатвить bitrix vm
Vestscp
braynycp
и тому подобное
Alex Wells,в задаче нет ни обьемов ничего.
Исходя из логики сколь либо значемый проект такоуй хренью не занимается и уж тем более не задают столь простые вопросы.
по этому говорить о какой-то системе кеширования и тд тут смысла нет.
тут очевидно делается костыль я лишь предлагаю его не распространять за пределы пхп
Виктор Таран, блин да не нужно было удалять комент.
опишите как вы добавляли сайт на сервер последовательность
ДНС запись меня пока не интересует.
Имено как создавались папки для сайта на сервере
Lola Gasanova, J о боженьки вы мне сейчас показали кирпич на вопрос о рыбе ;)
давайте по порядку где вы добавляли первое доменное имя покажите это место ?
именно когда создавали его на этом сервере ?
или вы это делали через конфиг ?
Alex Wells, затем что проксировать можно несколькими способами
nginx -proxy_pass
apache -mod_proxy
ну и пхп
так вот на сайте работают в основном разработчики php и естественно с php кодом они легко разберутся, не в момент его создания в в момент когда другй человек или через 3 года нужно будет вспомнить это место.
Если же делать это средствами самого сервера то
1. Вы привязаны к текущему конфигу и нужно всегоад помнить про его существование, что станет проблемой для нового разраба или всмомнить о этом тому-же через пару лет.
2. Вы используеете более обширный стэк технолгий, хоть и простых.
3. при востановление бэкапа на строннем сервере должен быть nginx или апачь соответственно в принудительном порядке, ибо конфиг нуно будет в него вписать или переделать под текущий веб сервер.
4. перенос на новый сервер, см пункт 3
И того для решения этой задачи хватает обычного разраба
против
двух сисадмина и разраба.
Это экономически дешевле обслуживать.
1 да все но, часть из них прокачивается под высоко частотные запросы часть под средни часть по точному вхождению.
Глупо надеиться на одинаковый трафик от запроса "купить трусы"
и "красные трусы с мехом в зеленый горошек. "
эти запросы имеют совершенно разные механизмы раскрутки разный процент конверсии и количество показов.
И да вы же не под каждый запрос делаете страницы, часть запросов будут не иметь страницы куда-то им нужно идти.
2 Да можно сделать их как отдельные страницы но вы можете нарушить структуру сайта , что отразится вам в дальнейшем при его росте.
тут нужно смотреть всю структуру сайта.
3 В примере не услуга разделяется территориально
а одно является вложением в другое, то что там территория в запросе попалась это всего-лишь пример.
Так же не забывайте что я вам указал одну статцнию метро, так же их 1000 штук, так же есть еще и города.
И тут структуризация очень важна, поскольку возможна канализация запроса, проблемы с фильтрациями построениями меню и тд и тп
У вас собрано семантическое ядро запросов ?
покажите вашу " сео карту"
пару урл- запрос куда какие вы собираетесь вести ?
Алексей, из минусов этого вы получите жесткую привязку сайта к nginx
если же вы сделаете как я сказал этой связки не получится, весь сайт се еще будет не привязан так полотно к среде
IvanovIvanIvanych, У вас должна быть страничка которую вы пркоачиваете для СЕО
К примеру у вас список спорт клубов, соответственно страница списка должна быть в поиске на более высоком месте по запросу
"Спортклубы кантемировская" нежели определенный спортклуб скажем Зебра, поскольку запрос не был зебра на кантемировской но спортклуб зебры явно более посещямеая чем какой-то подвал, соответствено яндекс
выбирая между
/sport_zebra
/sport_podval
выберет зебру как основную позицию на запрос "спортклубы кнтемировская"
Посколкьу ее посещяют чаще и дольше читают.
Для этого вы убираете зебру на более низкий уровень вложенности
/sport - эту страничку вы раскручивете ( тут все запросы кроме частных включая просто спортклубы москва)
/sport/zebra - частный случай когда запрос спортклуб зебра
так более понятно ?
А вот если вы раскручиваете моноуслуги к примеру "вскрытие замков" и это у вас основной профиль
то тут услуга может находиться вообще на главной странице, а все остальные услуги типа "востановление двери" уже находятся где-то там внутри. посколкьу они вам коммерчески не интересны и идут довеском.
Так более понятно ?
Но например допускается такая вещь /usluga-1 если вам нужно уменьшить уровень вложенности если это профильная для компании вещь.
Например у вас компания по ремонту телевизоров то да /remont_samsung вполне допустимо
нет как у вс не существует раздела ?
у вас есть более высокочастотный запрос чем частный случай услуги
как вы себ еэто представляете ?
если у вас две три моно услуги то да
если их больше чем 1-2 то нет такой ситуации быть не должно
ashyr96, такие костыли у каждого провайдера свои, однако это точно где-то в регионе поскольку в москве и области такой гадости давно уже ( лет 20 ) нет
давайте конкретный тариф в конккретном городе
дайте хоть почитать что они имеют в виду.
скорее всего это просто промо, ограничивать вас по длине маршрута сознательно никто не будет.
Все что может дать "игровой тариф" это увеличение скорости, качество при этом не должно меняться.
Скорость канала играм особо не нужна.
Качество сознательно понижать никто не будет. Как минимум это не совсем законно.
Если вы дадите ссылку на что именно вы имеете в виду "игровой тариф" то можно обсудить то в нем написано.
MrDimaFIX,
Открою вам секрет что если есть место не важно где но по дороге без шифрования, канал не может считаться защищеным.
В идиале нужно шифровать и бэк и фронт и тунель между ними.
НО последнее это как вы уже заметили возможно маразм для обычного веба.
Однако если у вас в ajax будет ифка с какой протокол то у вас будут проблемы.
если у вас будет АПИША с ожидаемым кодом 200 а у вас будет 301 то тоже проблемы
если у вас будет редирект с http_host = site.ru а он по факту на бэке будет site.ru:82 то тоже будут проблемы, и тд и тп.
я сейчас не говорю о самом шифрование канала я говорю о реальном определение бэком какой сейчас протокол. Посколку идет его подмена на фронте частично это исправляется но бэк работает на незащищеном и это полностью скрыть нельзя, в результате может быть все что угодно.
От зацикливания редиректов, котоырй гоняет по кругу один и тот-же урл вообще не еняя его.
Это не критично и на 95% проектов это вообще не заметно.
Но с точки зрения постороения архитектуру грубейшая ошибка.
Сделайте все правильно, дабы разница в 6 строк конфига.
В чем костыльность проброса сертификатов? никто вам не запрещяет кстати юзать разные.
Дмитрий, делаю в том же стиле что и было сделано тут, поверьте мне я тут такого насмотрелся что такая мешанина меня уже не смущяет.
как вам 47 JOIN к закроу ? из 4 бд ? и это тупо чтоб достать оферы. сумарно на проекте 58 мест подключений к 7 бд, дальше продолжать?
По этому я некоторые вещи пишу сам, поскольку объяснить программисту как тут все работает намного дольше чем повтыкать самому.
к веб серверу это отношение имеет посредственное.
Вам нужно установтиь веб сервер на вашу вм
самый прсотой вариант это сделать посатвить
bitrix vmVestscp
braynycp
и тому подобное