Поиск

Ваша картинка не про домен без HTTPS, а про кривой источник сертификата. Вы просто не умеете их готовить.

😂 вы это рассказываете дорвейщику с 20 летним стажем. никакая 'парковка ' не сравнится с дорвеями по количеству доменов и запросов. создать сервис парковки на 100500 доменов - хватит 5-10 баксового вдс. не закроют, скорее наоборот будет появляться больше центров сертификации валидирующих и выдающих сертификаты на домены, это уже понятный и прогнозируемый путь, https будет на каждом домене, а http будет запрещен и выпилен совсем, как опасный и устаревший подход. Уже сейчас просто так не попасть на домены без https:

Не будет, запрещено. Позволено делать wildcard сертификат только на один самый левый уровень. То есть для (w w w. one. site. tld) и (w w w. two. site. tld) надо генерировать не один wildcard сертификат, а два разных сертификата, в каждом из которых указать вариант с (w w w) префиксом, и без этого префикса. Вам уже много раз писали в этой теме, ресурсы жрёт не генерирование, а раздача контента с БОЛЬШОГО количества разных доменов. А когда закроют халявное генерирование, то придётся платить, или прощаться с кривыми HTTPS входящими указателями.

Там все упирается в ресурсы. Когда на сервере десятки или сотни тысяч хостов, обслуживание HTTPS-запросов обходится дороже, чем на обычном хостинге.

Выше писали про сервисы парковки (для продажи самого домена, а не размещения рекламы 'на домене '), насколько понимаю. Есть современные сервисы, которые тем не менее не позволяют использовать HTTPS или выпустить соответствующий сертификат для парковочной страницы домена. А свой VPS за $5 не все готовы держать. Нет большой разницы между HTTP и HTTPS применительно к парковочным страницам. У меня есть возможность выпускать и прикреплять сертификат к каждой парковочной странице домена, но для подавляющего большинства (парковочных страниц) доменов я этого не делаю.

проблемы создания ssl нет ни у кого уже много лет. это автоматизировано во всех панелях и это бесплатно. и в ближайшем будущем браузеры без плясок с бубном запретят вообще заходить на http сайты, будет только https везде, уже сейчас заходя на такой будет предупреждение, что сайт опасный и точно ли вы хотите на него зайти.

1. Сегодня бесплатны, а потом что будет, когда все входящие указатели с этим HTTPS префиксом? Эскалацию протокола с единым префиксом они делать не хотят, заодно и номер порта можно было бы экономить, а кривой специальный префикс, для которого обязательно нужен сертификат, насильно скармливают трудовому народу. 2. Кривой RFC не позволяет делать wildcard для SSL/TLS сертификатов так, как работает wildcard для DNS серверов, поэтому для больших сайтов не получится просто делать много SSL доменов нижнего уровня, поэтому всякие социальные сети дают кривой адрес страницы, как во времена (), вместо красивого домена нижнего уровня.

Добавлю, что попробовал отключить эту плашку, работает сейчас и без неё, так что, как и предполагал это просто совпадение. Пожалуй оставлю её включённой, звучит полезно вроде, если что отключить не сложно. Сама плашка находится: SSL/TLS - Edge Certificates - Automatic HTTPS Rewrites

подскажите, где можно почитать про подготовку CF под требования https в России

Они не умеют CF готовить под требования протокола https в России. Уже всё разжёвано, но люди не понимают хоть ты месяцами стучи по клавиатуре. Будет у них пропадать и дальше сертификат сайта или IPы из NS или просто таймаут соединения.

А вообще как верно пишут в основном в канал все упирается. И ещё часто в оперативку - мускуль съедает. Все остальное - гораздо реже. А ещё https под нагрузкой нередко глючит

Как я понял из гайдов и # комментов в самом конфиге можно поставить режим статик и постоянное кол-во дочерних процессов, то есть вот так: pm = static _children = 350. Именно так я и делал. И менял эту величину до 5000. А свободной памяти как оставалось условно 15-20 гигов, так и оставалось. Логи говорят такое: [proxy_fcgi:error] [pid 19309:tid 140075417446144] [client 93.95.162.143:60864] AH01067: Failed to read FastCGI header, referer: https://. [proxy_fcgi:error] [pid 19309:tid 140075417446144] (104)Connection reset by peer: [client 93.95.162.143:60864] AH01075: Error dispatching request to:, referer: https://.

Ладно он пошутил про Debian, а я пошутил про Ubuntu, у меня дома вообще Windows 10 самая лучшая бесплатная и свободная операционная система в мире:-). Ну сайт блога Microsoft как-то справляется - https:// blogs. windows. com /. (Не факт конечно, что он работает на Windows Server, но на WordPress уж точно). Честно скажу мне в целом все равно на чем запускается веб-сервер и отдает странички. Лишь бы не вис часто.

Попросил ЧатЖоПиТи посетить свой сайт, увидел такой User-Agent. А потом тьму таких же. Но вот я сомневаюсь, что это юзвери просят посетить мой сайт. Парсит? Ранее они чью-то базу использовали без своего парсера.

А как тогда исправить картинку, которая есть только в link rel = ' image_src ' href = ' https://..webp ' meta property = ' og:image:secure_url ' content = ' https://..webp ' meta name = ' twitter:image:src ' content = ' https://..webp ' и не присутствует на странице в другом виде?

Друзья, подскажите, пожалуйста. Собираемся запускать производство в Москве. Основной сайт у нас регион СПб. И в домене есть буквы spb. Хотел спросить, можно ли будет запустить сайт для Москвы на новом домене? Для Питера сайт у нас такой: https:// А для Москвы купили новый домен: https:// Получается, что на новом Московском сайте заменим только контакты: телефон, адрес производства. У меня 2 вопроса: 1. Так как это новый домен и на нем по факту будет копия первого сайта, есть ли у него потенциал по СЕО? Регионы разные: Питер и Москва соответственно. По факту же получается, что на этом новом домене будет копия чужого сайта. Ведь они никак не связаны. 2. Не отразится ли создание такого нового сайта-копии на позициях сайта основного ()? p. s. В поддержке Вебмастера сказали, что так как сайты в разных регионах то конкуренции быть не должно.

товарищи, я ЛОХ:-) письма о фишинге действительно были, за 10 дней до того, как влепили блок на два домена: вот текст: Cloudflare received a phishing report regarding: joXXXXXXXX[.]com[.]ru Below is the report we received: Reporter: Anonymous Reported URLs: hxxps://joXXXXXXX[.]com[.]ru Original Work: https:/ /ecommpay. com/ Logs or Evidence of Abuse: https: //j. ru/vXXXXXX/?aXXXXXXX=rXXXXXXXX1&id=17XXXXXXXX01 We have forwarded this complaint to your hosting provider. We have restricted access to the phishing-related content until it has been removed. To respond to this issue, please reply to abusereply@. Regards, Cloudflare Trust & Safety все сразу стало понятно. написал как в этом письме-предупреждении обратку на abusereply@ контент с указанных URLs удалил. очень надеюсь, что мои шансы снять блокировку-предупреждение о Фишинге с главных страниц двух сайтов высоки. всем спасибо за помощь теперь только сюда abusereply@ долбить с объяснением, что все исправлено/удалено

Да, так должно быть по задумке. Но щас вот смотрю логи Nginx и вижу, что он пропускает эти запросы, так как статики на подобный запрос у него быть не может. А бэкенд уже отдает 404 в Nginx обратно. Запрос всегда один и тот же: / - прям вот как есть, с косой чертой перед https. И всегда POST. А боты ведь GET делают, верно?

Да, 100% поисковый бот от Google, проверял по PTR записям. Ну и IP сразу выделяются из этой же ASN: 66.249.66.22, 66.249.66.23 и т.д. - как пример. Не, тут явно не тот случай, так как IP не фейковые, а настоящие. Тип запроса: POST, что говорит о том, что этот запрос реально пришел с сайта, указанного в реферере. Адрес указан неверно и явно намеренно, с косой чертой перед /https - это либо ошибка в скриптах на реф-сайтах, либо зачем-то еще так указывают, чтобы спамило именно в 404. Ну и сами рефки - сплошь полнейший жестяк! ))) Еще забыл добавить, что на сайте для всех настроен кэш, Nginx отдает статику всем, даже поисковым ботам - поэтому добраться до они не могут даже при большом желании. Это явно кто-то натравливает, указывая где-то у себя битую ссылку - но для чего и зачем? Подобные логи 404 вижу ведь только я ну и боты Google.

так скоро для всех запретят https.