Поиск

Давно хотел собрать это в одном месте сравнение вариантов для простой задачи: разместить статику (HTML/CSS/JS, лендинг, документация) на Object Storage без VPS. Везде S3-совместимый API, поддержка кастомного домена. Яндекс Object Storage Стандартное хранилище около 2 ₽/ГБ/мес. Из важного: первые 100 ГБ исходящего трафика каждый месяц бесплатно, первые 10 000 PUT и 100 000 GET операций тоже. Для небольшого сайта выходит практически бесплатно. При регистрации дают грант ≥4000 ₽ на 2 месяца. Статический хостинг настраивается из консоли, HTTPS через их Certificate Manager. Сам использую работает. Selectel Примерно те же ~2 ₽/ГБ, поддерживают статику прямо в документации. Из плюсов собственные ЦОД в РФ, давно на рынке, репутация надёжная. Минус нет такого щедрого free tier как у Яндекса, трафик считается отдельно. VK Cloud Hotbox (стандартный класс) ориентирован на раздачу контента. Статический хостинг поддерживается, но есть нюанс: HTTPS для статики работает только через HTTP (без SSL...

почему? мобильные операторы блокируют как то частично или первые https/2 запросы?

Меня одного удивляет, что такие банальные вещи нужно объяснять людям, которые считают себя IT-специалистами? Конечно же, никакой владелец VPN сервиса, и никакой товарищ майор, контролирующий коробку СОРМ, не могут декодировать проходящий чрез них HTTPS трафик - все шифруется еще в браузере, до отправки куда либо. И нет никаких 'массивов видеокарт ', вытаскивающих из этого трафика пароли от онлайн банков и т.д. Иначе, не было бы никаких банков давно, а скомпрометированный протокол пришлось бы срочно менять.

Какой стандарт? Рекомендация - кандидата)))) 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, может кто то может помочь в этой ситуации? Яндекс увы больше решать проблему не будет. На других сайтах сколько не смотрел, такой проблемы не видел.