По-перше, прошу вибачення, якщо я розмістив повідомлення про неправильний обмін, я дійсно не був впевнений, куди підходить це питання.
Протягом досить довгого часу у мене виникає ця дуже дивна проблема з домашнім підключенням до Інтернету, яка, безумовно, є або виною мого маршрутизатора, або помилкою мого провайдера, але мій Інтернет-провайдер досить безпорадний при його налагодженні.
Здебільшого мій зв’язок працює чудово - немає простоїв, і я постійно отримую майже 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