Сайт работает у меня, но не работает у других: причины

Если сайт открывается у вас, но не работает у других пользователей, это не доказывает, что сайт исправен. Ваш запрос проходит только по одному конкретному пути: через ваш resolver, провайдера, IP-версию, CDN edge, cookies и сетевые правила.

Практическая задача — найти, чем отличается успешный путь от неуспешного. Чаще всего расхождение находится в DNS-кеше, IPv4/IPv6, CDN/WAF, TLS, конкретном регионе, провайдере, браузерном состоянии или маршруте до origin.

Сначала зафиксируйте различия

Не просите пользователя просто «проверить ещё раз». Соберите:

• точный URL;
• время;
• регион;
• провайдер или сеть;
• устройство и браузер;
• текст ошибки;
• HTTP status, если он есть;
• используется ли VPN;
• проблема у одного пользователя или группы.

Если один пользователь видит DNS error, а другой HTTP 500, это два разных слоя проблемы.

Причина 1. Разный DNS-кеш

После изменения A/AAAA/CNAME разные resolver могут некоторое время видеть разные данные.

Проверьте:

dig example.com

Сравните с публичными resolver:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Смотрите не только наличие ответа, но и фактические адреса.

Если у вас DNS уже указывает на новый сервер, а у пользователя ещё на старый, это объясняет расхождение.

Причина 2. IPv4 работает, IPv6 сломан

Сайт может иметь A и AAAA. Один клиент предпочитает IPv6, другой идёт по IPv4.

Проверка:

curl -4 -i https://example.com/
curl -6 -i https://example.com/

Если IPv4 стабильно работает, а IPv6 нет, исследуйте AAAA, IPv6 routing, firewall, listener и CDN/origin configuration.

Не удаляйте AAAA вслепую: сначала подтвердите дефект.

Причина 3. Разные CDN edge

Пользователи из разных регионов могут попадать на разные edge nodes.

Симптом:

регион A → 200
регион B → 502
регион C → 200

Проблема может быть локальной для edge, origin route или конкретного backend pool.

Один успешный запрос владельца этого не покажет.

Причина 4. WAF или IP policy

WAF может блокировать:

• определённый IP;
• ASN;
• регион;
• User-Agent;
• bot-like pattern;
• частые запросы;
• подозрительный путь.

Если пользователь получает 403, сравните response headers и логи WAF.

Не отключайте WAF глобально только ради проверки. Лучше создать узкий диагностический сценарий.

Причина 5. Локальный браузерный кеш или cookies

У владельца может быть закешированная страница, активная сессия или service worker, а новый пользователь получает реальный сбой.

Проверьте:

1. приватное окно;
2. другой браузер;
3. curl;
4. очищенный cache только при необходимости.

Если curl получает 500, а браузер показывает старую успешную страницу, кеш маскирует проблему.

Причина 6. TLS отличается по пути

Разные клиенты могут видеть разные сертификаты из-за:

• CDN;
• SNI;
• корпоративного proxy;
• разных endpoint;
• неполной chain;
• устаревшего клиента.

Проверка:

openssl s_client   -connect example.com:443   -servername example.com   </dev/null

Сравнивать нужно результаты именно с проблемного пути, если это возможно.

Причина 7. Разные backend-инстансы

Load balancer может направлять вас на здоровый backend, а другого пользователя — на неисправный.

Пример:

backend A → 200
backend B → 500
backend C → 200

Тогда серия запросов покажет плавающий сбой.

Шаг 1. Проверьте сайт из независимой сети

Минимум:

• домашняя сеть;
• мобильная сеть;
• внешний мониторинг.

Если проблема воспроизводится извне, это уже не локальный браузер владельца.

Шаг 2. Сравните DNS

Запишите A/AAAA с успешной и неуспешной стороны.

успешно:   A = 203.0.113.10
неуспешно: A = 203.0.113.25

Разница даёт конкретное направление проверки.

Шаг 3. Сравните IPv4 и IPv6

curl -4 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com/
curl -6 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com/

Не все сети имеют рабочий IPv6; отсутствие возможности теста само по себе не доказывает проблему сайта.

Шаг 4. Снимите HTTP и timings

curl -sS -o /dev/null   -w 'remote=%{remote_ip} code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n'   https://example.com/

Сравните успешный и неуспешный путь.

Шаг 5. Используйте --resolve для проверки конкретного IP

curl -i   --resolve example.com:443:203.0.113.10   https://example.com/

Так сохраняются hostname и SNI, но соединение направляется на выбранный IP.

Это полезнее, чем запрос https://203.0.113.10/, который может попасть в неправильный virtual host.

Шаг 6. Локализуйте расхождение

одинаковый DNS?
 ├─ нет → DNS/cache
 └─ да
    одинаковая IP-версия?
     ├─ нет → IPv4/IPv6
     └─ да
        одинаковый TLS?
         ├─ нет → SNI/CDN/certificate
         └─ да
            одинаковый HTTP?
             ├─ нет → edge/WAF/LB/backend
             └─ да → browser/session/business layer

Если проблема только у одного пользователя

Сначала проверьте локальные причины:

• VPN;
• proxy;
• hosts file;
• DNS resolver;
• browser extension;
• корпоративный firewall;
• cookies/session;
• локальное время устройства для TLS;
• security software.

Но не списывайте всё на пользователя, пока не сравнили сетевой путь.

Если проблема у целого региона

Проверяйте:

1. CDN edge;
2. региональные WAF rules;
3. ISP routing;
4. DNS resolver;
5. GeoDNS;
6. IPv6;
7. origin reachability с этого региона.

Если сайт работает у владельца по VPN

VPN может менять DNS, IP, маршрут и регион CDN. Такой тест показывает только работоспособность через VPN, а не для обычных пользователей.

Как подтвердить восстановление

Проверка должна идти минимум из двух независимых точек:

точка A → DNS OK → TLS OK → HTTP 200
точка B → DNS OK → TLS OK → HTTP 200

и повторяться несколько раз.

Если один регион стабилен, а второй всё ещё падает, инцидент не завершён.

Почему внешний мониторинг полезнее ручной проверки

Владелец сайта естественно проверяет его из одной сети и часто уже авторизован. Внешний мониторинг даёт независимую точку наблюдения и фиксирует момент, когда код ответа или доступность изменились.

UpWatch можно использовать для регулярных внешних HTTP/HTTPS-проверок критичных URL, чтобы не полагаться на проверку только со своего компьютера.

Типичные ошибки

• считать свой 200 доказательством полной доступности;
• проверять только один resolver;
• игнорировать AAAA/IPv6;
• тестировать сайт по IP без Host/SNI;
• отключать WAF целиком;
• считать VPN нейтральной проверкой;
• закрывать инцидент после одного успешного запроса.

Практический чек-лист

1. Получить точный симптом пользователя.
2. Зафиксировать регион и сеть.
3. Сравнить DNS.
4. Сравнить IPv4/IPv6.
5. Снять curl timings.
6. Сравнить remote IP.
7. Проверить TLS/SNI.
8. Проверить CDN/WAF.
9. Проверить backend replicas.
10. Проверить browser/session слой.
11. Подтвердить recovery из нескольких точек.
12. Настроить внешний мониторинг.

Источники и документация

• curl: официальная документация
• OpenSSL s_client
• RFC 9110: HTTP Semantics