Час очікування з'єднання під час доступу до Github [закрито]

У мене точно така ж проблема, як описана тут: /programming/12849986/connection-timeout-when-accessing-github

Тож я просто скопіюю та вставте:

У мене є деякі дивні проблеми. Коли я намагаюся увійти в свій обліковий запис Github , я отримую помилку "net :: ERR_EMPTY_RESPONSE ".

Я спробував із Chrome, Firefox та Opera . У Firefox, якщо чистий кеш і офлайн-дані, він працює деякий час. Тоді я можу увійти, але я все одно не можу створити сховище Github, навіть якщо ще раз очищую кеш.

Мій друг , в одній мережі , в якій працює Windows, може робити все, що завгодно, на веб-сайті Github, але я не можу. Я спробував багато серверів DNS , я намагався не встановлювати його (мій друг не робить), але він все ще не працює .

Моя ОС: Ubuntu x64 12.04

Ідеї, будь ласка. І дякую.

Також я можу клонувати будь-які репо, але не можу натиснути. Мені довелося перейти на https://codeplane.com/ через цю проблему, але я хочу зрозуміти, чому це відбувається.

EDIT: Я міг би клонувати одне репо, але інше просто зависає на цьому етапі:

felipelalli@felipelalli-Studio-XPS-8100:~/wa$ git clone git@github.com:felipelalli/micaroni.git
Cloning into 'micaroni'...
remote: Counting objects: 5238, done.
remote: Compressing objects: 100% (3257/3257), done.
Receiving objects:  92% (4839/5238), 43.29 MiB | 902 KiB/s 

БУДЬ-ЯК поштовх висить так:

master!fml.eti.br> push
Counting objects: 23, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (19/19), 4.25 KiB, done.
Total 19 (delta 3), reused 0 (delta 0)

EDIT 2: Я форматую свій ПК і перевстановив Ubuntu, але проблема залишається такою ж. Отже, це усуває будь-які проблеми з установками або оновленнями. У мене є Dell Studio XPS.

EDIT 3: Я плачу 4 Bitcoin, якщо хтось вирішить мою проблему. Просто складіть свою публічну адресу.

EDIT 4: Коли я намагаюся натиснути, через кілька хвилин я отримую це повідомлення:

felipelalli@felipelalli-Studio-XPS-8100:~/wa/fml.eti.br$ git push
Counting objects: 26, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (22/22), 4.48 KiB, done.
Total 22 (delta 4), reused 0 (delta 0)
Write failed: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

Рішення:

після довгої нитки з підтримкою Github вони сказали, що це конфігурація на стороні сервера, пов'язана з попереднім попередженням атаки DDOS, яка торкнулася деяких користувачів, як я. Після деяких налаштувань на сервері Github все повертається до норми і знову працює дуже добре!

Дуже дякую команді підтримки Github, вони були дуже прозорими та корисними.

Цитата з довгої нитки електронної пошти:

Привіт Феліпе -

Ми відчували періодичні DDoS-атаки протягом останніх декількох тижнів, і прикрою побічною дією деяких запобіжних заходів, які ми ввели, є такі дивні побічні ефекти, як ця. Ми вважаємо, що проблема тут полягала в тому, що частина нашого захисту DDoS була неправильно налаштована. Ми працюємо з мережевим провайдером, щоб налаштувати захист DDoS, щоб не скидати подібний трафік з найвищим пріоритетом. Вибачте ще раз за неодноразові проблеми тут!

Джессі GitHub Ops

Гугл навколо вашого повідомлення про помилку виявляє деякі відомості про розмір MTU.

Якщо можливо, я пропоную спробувати іншу мережу / провайдер, щоб лише підтвердити, що це відбувається лише в цій конкретній мережі.

Потім ви можете спробувати змінити MTU (ви можете, наприклад, побачити, що Windows має для MTU, і встановити для цього Ubuntu; за замовчуванням це Ubuntu на 1500).

Ось як змінити MTU: http://ubuntuforums.org/showthread.php?t=1887063 .

Я пропоную вам спершу перевірити іншу мережу і лише потім спробувати змінити MTU. Це не те, що потрібно робити звичайно, тому якщо зміна мереж допомагає, я б сказав, що це якась дивна проблема з мережею, до якої Windows якось не видно.

Я можу допомогти вам діагностувати це, якщо ви вимкнете всі мережеві програми, окрім програми (git client у цьому випадку), щоб мінімізувати мережевий шум і використовувати tcpdump / wireshark для зйомки відправленого та отриманого трафіку, коли у вас виникнуть проблеми.

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

Встановіть обидві програми за допомогою:

sudo apt-get install wireshark tcpdump

а потім біжи

sudo tcpdump -i wlan0 -o dump.pcap -s 1500

почати захоплення перед тестуванням.

Було б корисно, якщо ви захопите трафік під час одного сеансу, який не вдається, і завантажте отриманий dump.pcap кудись, де я міг би його завантажити.

Якщо ви не відстаєте від проксі, ігноруйте цей коментар.

Я за плечима проксі, і мені довелося налаштувати git, щоб дістатися через нього. До цього у мене були тайм-аути на github на машині Ubuntu, тоді як машини Windows працювали чудово.

Тож якщо ви за проксі, відкрийте файл ~ / .gitconfig і додайте ці рядки:

[http]
    proxy = http://192.168.219.2:8080
[https]
    proxy = https://192.168.219.2:8080

Звичайно, замініть IP та номери портів на ваші. Сподіваюсь, це допомагає

Я отримував цю помилку під час виконання "оновлення варіння" у своєму командному рядку (терміналі):

fatal: unable to access 'https://github.com/Homebrew/homebrew/': SSLRead() return error -36 Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

Я також помітив, що жоден із моїх браузерів не зміг підключитися до github.comвеб-сайту.

Я вирішив усі проблеми з підключенням між моїм Mac OS X Mavericks і github, переключивши мережеве з'єднання Wi-Fi з 802.11n (5.18GHz) на 802.11g (2.412GHz).

Я не знаю, чому це працювало для мене, але я просто радий, що це повернулося до норми.