Поиск

Какой стандарт? Рекомендация - кандидата)))) 15 минут ушло на то чтобы попасть вот сюда И прям сразу прочитать что это НЕ НОРМАТИВ, а временный костыль. И еще узнать какие проблемы он решал во времена массового перехода на HTTPS. - Клиент мог сообщить чтоб он в состоянии подключиться по https - Сервер мог сообщить чтоб все ссылки из http превращались в https Там даже примеры есть. А еще там есть о том, что он никак не заменяет и не пытается заменить ПРОТОКОЛ, СТАНДАРТ RFC 6797. И что следовать нужно ему. А он как раз жестко шлет на https и рвет соединение если безопасность не обеспечена.. ща конечно другие стандарты, повыше чем высокие. Но я уже допил кофе, простити.

откуда ты эту дичь берешь? просто читай в первоисточнике:   там кстати и про переезд с http на https описано, что юзать 301.

потому что у тебя полное непонимание что это и для кого это. это рекомендация браузеру, что если тебе надо эта безопасность то перейди на https. яндекс во первых не браузер, а бот, и ему без разницы кто там какой запрос подменит между ним и твоим сервером, что получит, то и проиндексирует. но на дворе 2026, все сайты должны быть на https, это не просто правило хорошего тона, это база. ставить 301 с http это норма. ftp кстати умер лет 15 назад, его давно не должно быть, потоvу что есть sftp.

Давай на пальцах. Впн это инкассаторская машина. У владельца Впн есть ключи от самой машины, он может ее открыть и посмотреть, сколько внутри сейфов и куда их везут. Но ключей от самих сейфов (https-трафика) у него нет, они лежат только у тебя и у банка. Чтобы вскрыть сейф на ходу, ему нужно распилить его болгаркой, и твой браузер это сразу заметит, выдав красную ошибку невалидного сертификата

Если трафик идет по https или через протоколы мессенджеров, то для владельца vpn он выглядит как криптографический мусор. Никакой 'левый vpn ' не сможет расшифровать ваш банковский трафик или переписку без установки своего корневого сертификата на ваше устройство. Максимум что они видят - это IP-адрес сервера к которому вы обращаетесь, и объем переданных данных

Тут в треде всё смешали в кучу куки, персональные данные, метрику, РКН. Давайте разложим по полочкам, потому что куки кукам рознь. Что такое кука технически? Это пара ключ=значение, которую сервер просит браузер сохранить. Всё. Сама по себе кука это не персональные данные, точно так же как пустой конверт это не письмо. Какие куки НЕ являются персональными данными: Сессионные куки ( PHPSESSID, session_id ) живут до закрытия браузера, нужны чтобы сайт работал. Без них не будет корзины, авторизации, CSRF-защиты. Это техническая необходимость, а не сбор данных. Функциональные куки язык интерфейса, тема оформления, cookie_consent=yes (ирония сама кука о согласии на куки). Никакой идентификации пользователя. First-party куки без привязки к личности например, last_visited_page=/catalog. Нет ни email, ни IP, ни имени. Это не ПД ни по ФЗ-152, ни по GDPR. Какие куки ЯВЛЯЮТСЯ (или могут являться) персональными данными: Куки трекинговых систем: _ym_uid (Метрика), _ga (Google Analytics)...

Люто плюсую ТС, тоже недавно делал реверс прокси, тоже с помощью Opus. Причём реверс прокси для 5 разных доменов в одном VPS прокси, ии сделал всю работу за раз два. Из-за блокировки РКН пришлось написать https API + CDN, и опять же Opus все сделал за пару часов.

Складывается впечатление, что это сами 'патентные тролли ', как их тут называют, распространяют бредятину о том, что всё можно и бояться нечего. Товарищ практик может подробнее рассказать о блокировке ркном конкретной отдельной страницы, когда сайт работает по https?

если убрать галочку 'всегда HTTPS ', то сайт начинает работать по http без проблем даже при включенном проксировании. но как разместить свой ssl сертификат на бесплатном тарифе CF пока непонятно

Если: с первым и вторым доменом всё хорошо; если нет ошибок; если технически переезд выполнен без ошибок; если смена домена оформлена в панели вебмастера; если добавили в панель вебмастера все версии старого и нового доменов (c www, без www, http и https) и для каждой оформили переезд - спорный 'каргокультовый ' мув, но почему бы и нет; если нет никаких ворнингов в вебмастерах. То ждать придётся в среднем 1.5 года или несколько core update. ~17% переехавших сайтов так и не восстановились. Почитайте моё мини исследование проблем после переезда - #comment_17179607 С 301-м редиректом у гугла реально есть проблемы. Запланированные или нет - точно неизвестно. Я думаю, что специально так сделали. Редирект ничего больше для этой ПС не значит, кроме того, что самих юзеров перекидывает. По крайней мере первое время ничего не значит. Если домен, на который переехали - новый, то редирект на него никакой вес не передаёт и новый домен расценивается именно, как новый сайт, а не переехавший со...

А сертификат Let's Encrypt? У меня подобная хрень началась. С https не доступен сайт, без доступен

Попробуй так, у меня работает. RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Недавно правил редиректы в хтассесс, чтобы увидеть результат пришлось менять браузер, до этого казалось, что не работает. Поэтому предположил насчет смены браузера. Вот как у меня в хтассес устроен www и https редирект Работает. По идее, в хтассесс должно сработать раеньше чем CMS начнёт мутить, поэтому не важно Dle или что. Возможно порядок - повыше поднять.

Так у вас в первом случае, а во втором https:// m.:

Это старый код который яндекс почему-то не желает исправить. Запросы идут по http и мы получаем микс контент. Новые версии браузеров типа хрома сами блокируют http и пытаются подменить на https.

Сертификат https обновляли?

Такая ситуация, недавно обнаружил при проверке страниц сайта через пишется что: Протокол HTTPS не используется Обнаружено 3 небезопасных запроса. Все запросы от рекламной сети Яндекса, написал в поддержку Яндекса, неделю решали вопрос, в итоге один запрос исчез но осталось еще два, оба ведут на, в Яндексе сказали что у них все нормально и вопросы к ' логике аудита PageSpeed ', но при этом один запрос они все же убрали, значит проблема не в PageSpeed, может кто то может помочь в этой ситуации? Яндекс увы больше решать проблему не будет. На других сайтах сколько не смотрел, такой проблемы не видел.

Второй день идут какие-то вялые шевеления: Из того, что сделал за последние две недели: добавил в общей сложности 8 вариаций сущностей в Search Console: новый сайт с https и без, c www и без + их комбинацию и то же самое для старого сайта; для всех сущностей оформил переезд на основной домен - на https без www (да, повторно оформил переезд получается); через Indexing API отправлял разные ссылки, но судя по консоли это не дало вообще никакого эффекта, так как изменений по страницам не было (хотя может это дало гуглу какой-то сигнал, я хз). Новых страниц добавлено не много, не более 20 штук, разношёрстные: статьи, новости и страницы каталога. Ссылки за этот период не закупались. Надеюсь гугл ожил, а не в очередной раз что-то там тестирует. Но за последний год - это самый щедрый с него трафик.

Если изначально перенаправляет на https:// с http://, http://www. и https://www., то это уже очень много )))))

Шёл 11-й месяц переезда. Сообщение в серч консоли давно пропало. Яндекс продолжает наваливать трафика: Google молчит. Почитал эти Ваши интернеты, что буржуи пишут, плюс запустил GPT агента, который напарсил реальных схожих кейсов потери трафика после смены домена. Выводы: Даже идеальный переезд ничего не гарантирует. Средний срок восстановления и возврата прежних позиций - 523 дня (1.5 года). Около 17% переехавших сайтов никогда не восстанавливаются. Не существует ни одного достоверно известного и подтвержденного способа восстановления. Что делали те, кто восстановил трафик: продолжали наполнять сайт качественными материалами, усиливали продвижение и размещали ссылки, некоторые плевали на переезд и восстанавливали сайт на старом домене. Из неочевидного, попахивает 'карго культом ', некоторые вебмастеры заводили в Search Console аж 8 (!!!) сущностей: старый домен с https, старый домен с http, старый домен с https и www, старый домен с http и www, новый домен с https (основной),...