- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет.
Подскажите, пожалуйста чем может быть связана данная проблема. Стоит на сайте включить запросы на SSL, так от пользователей (их очень мало, посещаемость сайта 10к человек в сутки, а фидбэк составляет 10-15 человек из общего числа) поступают жалобы о том, что сайт становится недоступен. Ошибка, которую они все как один видят - соединение сброшено.
Я пытался понять, в чем дело - ведь у меня то проблемы нет, и у других тысяч людей тоже. Путем долгой диагностики мне удалось получить некоторые точки, из которых можно было обратится к сайту по https и получить connection reset. Получив их IP, я начал анализировать весь приходящий на сервер трафик, и вот что выяснилось опытным путем:
1) клиент посылает соединение на сервер, указав порт 443 и свой ip - запрос принимается сетевой картой, он фигурирует в логах. Т.е. получается, запрос пришел
2) дальше этот запрос теряется. При попытках дебажить логи nginx (он у нас в качестве фронтенда), утилитами tcpdump и tcpflow нет никаких намеков на то, что запрос дошел до nginx (нет никаких упоминаний проблемных IP в логах).
т.е. на уровне jnettop запрос есть, висит какое-то время, а потом пропадает. при этом сервер не отправляет трафика по данному запросу, т.е. строка TX всегда была пустой.
С чем это может быть связано? Вероятно, людей, у которых такая проблема проявилась больше, чем 15 фидбэков.
Надеюсь, вы сможете мне помочь. Заранее благодарен.
---------- Добавлено 05.09.2016 в 00:29 ----------
но самое интересное в этой ситуации так это то, что стоит перевесить сайт на другой IP - так проблема сразу сама собой решается. Даже с проблемных точек сайт начинает открываться.
У вас "подземный стук". Пока вы не сможете гарантированно повторить проблему - он так и будет "подземным стуком".
Проверьте тут https://www.ssllabs.com/ssltest/ свой сайт. Может выявит проблемы, например у юзеров сильно старинные браузеры.
но самое интересное в этой ситуации так это то, что стоит перевесить сайт на другой IP - так проблема сразу сама собой решается. Даже с проблемных точек сайт начинает открываться.
ну так проверьте этот IP в реестрах заблокированных сайтов всяких.
ну так проверьте этот IP в реестрах заблокированных сайтов всяких.
так на 80 порту работает всё, не работает только 443 у этих юзеров. будь ip в реестрах, то вообще доступа бы не было
Проверьте тут https://www.ssllabs.com/ssltest/ свой сайт. Может выявит проблемы, например у юзеров сильно старинные браузеры.
по тестам там только у пары браузеров connection closed, и те на xp и IE 6-8. у тех, кто оставлял фидбэк, судя по отчету, стоит win7-win10 и браузеры вообще любые, в т.ч. и хром.
так на 80 порту работает всё, не работает только 443 у этих юзеров. будь ip в реестрах, то вообще доступа бы не было
Ну зачем вы мне что-то доказываете? Это ваш сайт и ваш интерес.
Не хотите - не ищите.
А я напомню, что в реестре не IP, а "материалы".
По 80 порту фильтрация отдельных материалов по URL в состоянии работать нормально, а по 443 может блокироваться IP целиком. Закон просто декларирует необходимость ограничить доступ, а конкретные реализации могут отличаться и глючить разнообразно.
Ну зачем вы мне что-то доказываете? Это ваш сайт и ваш интерес.
Не хотите - не ищите.
А я напомню, что в реестре не IP, а "материалы".
По 80 порту фильтрация отдельных материалов по URL в состоянии работать нормально, а по 443 может блокироваться IP целиком. Закон просто декларирует необходимость ограничить доступ, а конкретные реализации могут отличаться и глючить разнообразно.
я бы не был так уверен в своих словах, если бы этот IP был в каких-либо всевозможных списках запрещенных материалов. Но его там нет, в общем-то. Но я еще раз повторюсь, будь он там, то у бОльшей части провайдеров сайт бы неминуемо блокировался (либо ip). Но проблема не зависит ни от территориального расположения провайдера пользователя, ни от самого провайдера.