Привет.
Мы делаем сервис связанный с анализом пользователей. Суть работы примерно следующая:
- юзер кликает на ссылку;
- юзер перенаправляется на адрес на нашем сервисе;
- сервис делает магию;
- сервис перенаправляет юзера на целевую страницу;
Домены на каждом из адресов могут не совпадать. В некоторых случаях требуется делать редирект через https и тут возникают проблемы: теряется до трети тестового трафика (не доходит до нашего сервиса). Возможности словить юзера и спросить «что не так?» нету.
Вывод о потерях делается на осное сопоставления юзеров, кликнувших по ссылке, и юзеров пришедших к нам (т.е. установивших ssl соединение и сделавших запрос url).
Тестовый трафик, мягко говоря, дешёвый и плохой и теряется даже без использования https (нормальные потери порядка 10%), но с включением шифрования потери резко возрастают. Необходимо их устранить или убедиться, что они «естественны» (например, всё это боты).
Сертификат куплен у Godaddy.
Сервисы проверки ssl вида
https://www.ssllabs.com/ssltest/analyze.html?d=rou... говорят, что цепочка доверия настроена корректно.
По анализу User-Agent, основные потери приходятся на последние версии браузеров (в основном Chrome, т.к. трафик в основном на этом браузере). Операционные системы: Windows 7 (2 трети трафика), Windows XP (треть).
Часть конфига Nginx с настройкой sslserver {
listen route.land:80;
server_name route.land;
listen route.land:443 ssl;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL;
ssl_stapling on;
ssl_stapling_verify on;
ssl_certificate /etc/nginx/ssl/route.land.crt;
ssl_certificate_key /etc/nginx/ssl/route.land.key;
ssl_trusted_certificate /etc/nginx/ssl/route.land.trusted.crt;
resolver 8.8.8.8;
}
Ссылка на сайт
https://route.land
Ссылка для проверки цепочки редиректов:
the-tale.org/test (должно возвращать на
the-tale.org/)
На текущий момент есть следующие версии:
- глупые боты, т.к. трафик дешёвый и рекламный (4% потеряных при переходе на https юзеров прямо в User-Agent пишет что боты).
- кривые пиратские оси, в которых отключено автоматическое подтягивание корневых сертификатов (слабо верится, не ясно зачем отключать, проверил на пиратской семёрке 2010 года, всё работает).
- какие-то распространённые корпортативные конфигурации, блокирующие сайт (большинство тестов проводилось в выходные, так что вряд ли).
- сторонний софт (антивирусы и прочее), точно знаю что Касперский может ломать ssl при некоторых настройках (они у себя так и пишут), но процент таких поломок не знаю.
- один из нюансов работы браузеров с безопасными соединениями, который мне не удалось нагуглить.
Подскажите в чём ещё может быть проблема, куда копать?
UPDATED:
По логам nginx:
- у нас мало очень малое количество ошибок на этапе рукопожатия;
- в access log и error log с loglevel=error нет записей о потерянных пользователях.
Сделал два небольших теста с loglevel=info для error log (редирект через http и https):
- 5% уникальных IP вообще не пытаются подключаться к нам в обоих тестах;
- 17% уникальных IP закрывают соединение после установки https соединения (потерь при http нет). Распределение ошибок следующее:
- 16% — client timed out (110: Connection timed out) while waiting for request;
- 90% — client closed connection while waiting for request;
- 4% — peer closed connection in SSL handshake while SSL handshaking.
Разница между временем перенаправления пользователей на наш сайт и временем появления ошибок (для пользователей, которые не делали ничего, кроме установления соединения) составляет 10-20 секунд.
Простой
Простой
Средний
