Дуже дивна проблема з мережею - конкретні сайти не завантажуються


8

По-перше, прошу вибачення, якщо я розмістив повідомлення про неправильний обмін, я дійсно не був впевнений, куди підходить це питання.

Протягом досить довгого часу у мене виникає ця дуже дивна проблема з домашнім підключенням до Інтернету, яка, безумовно, є або виною мого маршрутизатора, або помилкою мого провайдера, але мій Інтернет-провайдер досить безпорадний при його налагодженні.

Здебільшого мій зв’язок працює чудово - немає простоїв, і я постійно отримую майже 100% швидкості, за яку я плачу.

Однак є одна конкретна проблема: деякі веб-сайти мають дуже дивну поведінку, коли завантажуватимуться дуже багато часу. Прикладами таких веб-сайтів є en.wikipedia.org, www.canadapost.ca та www.theweathernetwork.com. З цими веб-сайтами щоразу, коли я намагаюся завантажити сторінку, спочатку нічого взагалі не завантажуватиметься, і рядок стану в Chrome дуже довго буде читати "Встановлення безпечного з'єднання ..", і з часом це дасть мені " Помилка доступу до цього сайту " Якщо я перезавантажуюсь і спробую ще раз, через кілька разів сайт з часом завантажиться, і коли цей веб-сайт завантажений, я можу вільно переглядати цей веб-сайт без проблем протягом приблизно 15 хвилин або близько того, тоді проблема повернеться.

Це не проблема з налаштуваннями мого брандмауера чи ПК. Я вже спробував чимало речей, щоб усунути проблему, і я визначив, що це повинен бути моїм модем-маршрутизатором, або самим моїм підключенням до Інтернету, тому що це відбувається з усіма пристроями, підключеними до моєї мережі (настільний ПК, ноутбук, смартфон тощо) і зі своїм смартфоном, коли я переключаюсь на мобільні дані, проблема відходить.

Я зареєстрував у своєму Інтернет-провайдері службу підтримки, і вони провели мене через усі очевидні кроки (скидання фабрики на модем тощо), і тепер вони не дуже корисні.

Одне, що я зробив, щоб спробувати перевірити, - це запустити команди curl для веб-сайтів, які мають цю проблему, і я щось помітив; з усіма веб-сайтами, які мають цю проблему, "curl -v [url]" повертає HTTP 301 замість 200.

Хтось має ідею, що це, до біса, викликає, щоб я міг вказати техніків свого провайдера в правильному напрямку?

EDIT: Було зазначено, що я не включав https у команди curl, що спричинило повернення 301. Але тепер, коли я включаю https, я помітив щось цікаве:

Під час запуску curl -v на веб-сайті https, який не є частиною проблеми (наприклад, у Facebook), я закінчую звичайний вихід. Але для веб-сайту, який виглядає так:

$ curl -v https://www.canadapost.ca
* STATE: INIT => CONNECT handle 0x600057810; line 1413 (connection #-5000)
* Rebuilt URL to: https://www.canadapost.ca/
* Added connection 0. The cache now contains 1 members
*   Trying 2600:140a:0:18a::1dc5...
* TCP_NODELAY set
* STATE: CONNECT => WAITCONNECT handle 0x600057810; line 1466 (connection #0)
*   Trying 23.34.200.189...
* TCP_NODELAY set
* Connected to www.canadapost.ca (2600:140a:0:18a::1dc5) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057810; line 1583 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057810; line 1597 (connection #0)

Потім він висить там дуже довго, а згодом він продовжується і закінчується:

* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CA; ST=Ontario; L=OTTAWA; O=Canada Post Corporation; OU=Akamai SAN SSL OV; CN=www.canadapost.ca
*  start date: Jan 13 00:00:00 2017 GMT
*  expire date: Jan 13 23:59:59 2018 GMT
*  subjectAltName: host "www.canadapost.ca" matched cert's "www.canadapost.ca"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SSL CA - G3
*  SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x600057810; line 1618 (connection #0)
> GET / HTTP/1.1
> Host: www.canadapost.ca
> User-Agent: curl/7.54.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x600057810; line 1680 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x600057810; line 1807 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x600057810; line 1817 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 301 Moved Permanently
* Server AkamaiGHost is not blacklisted
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://www.canadapost.ca/web/en/home.page
< Date: Mon, 22 May 2017 22:01:55 GMT
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000
<
* STATE: PERFORM => DONE handle 0x600057810; line 1991 (connection #0)
* multi_done
* Connection #0 to host www.canadapost.ca left intact
* Expire cleared

Схоже, це може бути проблема IPv6. Що ви отримуєте, перейшовши на цей веб-сайт: test-ipv6.com
Моше Кац

Також, що станеться, якщо вимкнути IPv6 на комп’ютері чи маршрутизаторі (спробуйте будь-який)?
Моше Кац

У якому ти стані? Ми спостерігаємо таку саму поведінку, і всі веб-сайти, включаючи ваш, розміщуються на Akamai.
Чад

@MosheKatz Я спробую це, коли сьогодні приїду додому.
користувач1072692

@Chad Онтаріо, Канада
користувач1072692

Відповіді:


4

Це врешті-решт було спричинене IPv6. Я відключив його на моєму маршрутизаторі і встановив його лише на IPv4, і тепер проблеми вже немає.


2

Усі три ці сайти здаються лише HTTPS. Якщо ви починаєте, які http://адреси, ці сайти інформують ваш веб-переглядач, що вони постійно переходять httpsна 301 повідомлення. Це буде частиною повідомлення 301. Ви можете отримати додаткові переадресації, які додають шлях до сторінки за замовчуванням. Переадресація 301, швидше за все, червона оселедець.

Тривалі затримки, як це, є звичайними, якщо у вас проблеми з DNS-коннективністю. Однак я б очікував, що це станеться з першої спроби.

Усі ці сайти підтримують IPv6. Якщо вам здається, що у вас є можливість IPv6, Chrome, швидше за все, намагатиметься використовувати IPv6, а не iPv4 для підключення. Переговори HTTPS можуть включати декілька підключень до різних серверів. Якщо будь-яка з них заблокована або закрита, це може спричинити затримки.

Це може допомогти використовувати інструменти для розробників Chome ( CtrlShifti. Виберіть вкладку «Мережа», яка покаже час завантаження компонентів сторінки. Наведіть курсор на перше повільне з'єднання для отримання детальної інформації про таймінги.


1
Дякуємо, що вказали на https, що викликає 301, про це повністю забув. Я знову запустив curl за допомогою https, і я помітив щось цікаве .. https-сайти, які не мають цієї проблеми (наприклад, у Facebook), завантажують чудово .. "curl facebook.com " працює чудово. Але на веб-сайтах, які мають цю проблему, відгуки про
згортання
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.