У меня есть приложение, которое отлично работает на Xcode6-Beta1 и Xcode6-Beta2 с iOS7 и iOS8. Но с Xcode6-Beta3, Beta4, Beta5 у меня возникают проблемы с сетью в iOS8, но на iOS7 все работает нормально. Я получаю ошибку "The network connection was lost."
. Ошибка заключается в следующем:
Ошибка: Ошибка Домен = NSURLErrorDomain Код = -1005 «Сетевое соединение потеряно». UserInfo = 0x7ba8e5b0 {NSErrorFailingURLStringKey =, _kCFStreamErrorCodeKey = 57, NSErrorFailingURLKey =, NSLocalizedDescription = Сетевое соединение было потеряно., _KCFStreamErrorDomainKey = 1, соединение NSUnder0e0707) 07.
Я использую AFNetworking 2.x и следующий фрагмент кода для выполнения сетевого вызова:
AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
[manager setSecurityPolicy:policy];
manager.requestSerializer = [AFHTTPRequestSerializer serializer];
manager.responseSerializer = [AFHTTPResponseSerializer serializer];
[manager POST:<example-url>
parameters:<parameteres>
success:^(AFHTTPRequestOperation *operation, id responseObject) {
NSLog(@“Success: %@", responseObject);
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
NSLog(@"Error: %@", error);
}];
Я пытался, NSURLSession
но все равно получаю ту же ошибку.
ios8
ios-simulator
xcode6
xcode6-beta5
VoidStack
источник
источник
Ответы:
Перезапуск симулятора исправил проблему для меня.
источник
У нас была именно эта ошибка, и это оказалось проблемой с базовой реализацией HTTP
NSURLRequest
:Насколько мы можем судить, когда iOS 8/9/10/11 получает ответ HTTP с
Keep-Alive
заголовком, она сохраняет это соединение для повторного использования позже (как и должно быть), но сохраняет его больше, чемtimeout
параметр Keep-Alive header (кажется, он всегда поддерживает соединение в течение 30 секунд.) Затем, когда приложение отправляет второй запрос менее чем через 30 секунд, оно пытается повторно использовать соединение, которое могло быть сброшено сервером (если прошло больше реальногоKeep-Alive
).Вот решения, которые мы нашли до сих пор:
KeepAliveTimeout
опцию.BrowserMatch "iOS 8\." nokeepalive
в файле модаsetenvif.conf
)Connection: close
заголовком: это скажет серверу немедленно прекратить соединение и ответить без заголовков поддержки активности. НО в настоящий момент NSURLSession, кажется, переопределяетConnection
заголовок при отправке запросов (мы не тестировали это решение всесторонне, так как мы можем настроить конфигурацию Apache)источник
NSURLErrorNetworkConnectionLost
константу вместо жесткого кодирования-1005
.По моему,
Resetting content and settings
Симулятор работает. Для сброса симулятора выполните следующие действия:источник
Во время выполнения симулятора iOS 8.0 имеется ошибка, из-за которой, если ваша сетевая конфигурация изменяется во время загрузки имитируемого устройства, высокоуровневые API (например, CFNetwork) в симулированной среде выполнения будут думать, что они потеряли сетевое соединение. В настоящее время рекомендуемый обходной путь - просто перезагрузить моделируемое устройство при изменении конфигурации сети.
Если вы столкнулись с этой проблемой, отправьте дополнительные дубликаты радаров по адресу http://bugreport.apple.com, чтобы повысить их приоритетность.
Если вы видите эту проблему, не изменив конфигурацию сети, то это не известная ошибка, и вам обязательно нужно подать радар, указывая, что проблема не в известной ошибке, измененной в конфигурации сети.
источник
что решило проблему для меня, так это перезагрузить симулятор и сбросить содержимое и настройки.
источник
Также есть проблема с бета 5 и AFNetworking 1.3 при работе на симуляторе iOS 8, которая приводит к ошибке соединения:
Тот же самый код прекрасно работает на симуляторах iOS 7 и 7.1, и мой прокси-сервер отладки показывает, что сбой происходит до того, как соединение действительно предпринято (т. Е. Запросы не регистрируются).
Я отследил сбой NSURLConnection и сообщил об ошибке в Apple. Смотрите строку 5 на прикрепленном изображении:
,
Изменение использования
https
позволяет подключаться к симуляторам iOS 8, хотя и с периодическими ошибками.Проблема все еще присутствует в Xcode 6.01 (gm).
источник
Я испытывал эту проблему при использовании Alamofire. Моя ошибка состояла в том, что я отправлял пустой словарь
[:]
для параметров поGET
запросу, а не отправлялnil
параметры.Надеюсь это поможет!
источник
Открытие Чарльза решило проблему для меня, что кажется очень странным ...
источник
Смотрите комментарий pjebs 5 января на Github.
Метод 1:
Также некоторые предлагают повторно подключиться к сайту,
т.е. запускаем POST-запрос ДВАЖДЫ
Решение: Используйте метод для подключения к сайту, верните (id), если сетевое соединение было потеряно, вернитесь, чтобы использовать тот же метод.
Способ 2
источник
Я тоже получал эту ошибку, но на реальных устройствах, а не на симуляторе. Мы заметили ошибку при доступе к нашей серверной части heroku по HTTPS (серверу gunicorn) и при выполнении ПОСТОВ с большими телами (что-нибудь более 64 КБ). Мы используем HTTP Basic Auth для аутентификации, и заметили, что ошибка была устранена, НЕ используя
didReceiveChallenge:
метод делегата в NSURLSession, а вместо этого вставляя аутентификацию в заголовок исходного запроса путем добавленияAuthentiation: Basic <Base64Encoded UserName:Password>
. Это предотвращает необходимые 401, чтобы инициироватьdidReceiveChallenge:
сообщение делегата, и последующее сетевое соединение потеряно.источник
У меня была такая же проблема. Решение было простым, я установил
HTTPBody
, но не установленHTTPMethod
вPOST
. После исправления все было хорошо.источник
У меня такая же проблема. Я не знаю, как AFNetworking реализует запрос https, но причина для меня - проблема с кешем NSURLSession.
После отслеживания моего приложения из safari и последующей отправки запроса http появится сообщение «Ошибка загрузки http 1005». Если я перестану использовать
"[NSURLSession sharedSession]"
, но использовать настраиваемый экземпляр NSURLSession для вызова метода «dataTaskWithRequest:», как указано ниже, проблема решена.Просто не забудьте установить
config.URLCache = nil;
.источник
Мне пришлось выйти из XCode, удалить содержимое папки DerivedData (~ / Library / Developer / Xcode / DerivedData или / Library / Developer / Xcode / DerivedData) и выйти из симулятора, чтобы сделать эту работу.
источник
У меня также есть эта проблема, работающая на устройстве iOS 8. Это подробно описано здесь и похоже на случай, когда iOS пытается использовать соединения, для которых уже истекло время ожидания. Моя проблема не совпадает с проблемой Keep-Alive, описанной в этой ссылке, но, похоже, это тот же конечный результат.
Я исправил свою проблему, выполнив рекурсивный блок всякий раз, когда я получаю сообщение об ошибке -1005, и это в конечном итоге приводит к соединению, хотя иногда рекурсия может зацикливаться более 100 раз, прежде чем соединение заработает, однако при запуске добавляется всего лишь секунда раз, и я держу пари, что это только время, которое требуется отладчику для печати NSLog для меня.
Вот как я запускаю рекурсивный блок с AFNetworking: добавьте этот код в ваш файл класса соединения
Тогда используйте это как это:
Вы увидите, что я использую
AFHTTPRequestOperation
подкласс, но добавляю ваш собственный код запроса. Важной частью является вызовrecurse(@offset.intValue+1));
для повторного вызова блока.источник
Если проблема возникает на устройстве, проверьте, проходит ли трафик через прокси (Настройки> Wi-Fi> (информация)> HTTP Proxy). У меня была настройка устройства для использования с Чарльзом, но я забыл про прокси. Кажется, что без Чарльза на самом деле работает эта ошибка происходит.
источник
Если кто-либо получает эту ошибку при загрузке файлов на внутренний сервер, убедитесь, что на принимающем сервере установлен максимальный размер содержимого, допустимый для вашего носителя. В моем случае NGINX требовал более высокого
client_max_body_size
. NGINX отклонит запрос до завершения загрузки, поэтому код ошибки не возвращается.источник
Я получал ошибку на устройстве iOS 7, когда я использовал бета-версию Xcode 6.2.
Переход с бета-версии Xcode 6.2 на 6.1.1 исправил проблему, по крайней мере, на устройстве iOS 7.
источник
На
2017-01-25
Apple выпустили технический Q & A относительно этой ошибки:источник
Получил проблему в течение нескольких месяцев, и, наконец, обнаружил, что когда мы отключаем DNSSEC на нашем домене API, все было в порядке: simple_smile:
источник
Я подключался через VPN. Отключение VPN решило проблему.
источник
Я нажимал эту ошибку при передаче NSURLRequest в NSURLSession без установки HTTPMethod запроса .
Добавьте
HTTPMethod
, хотя, и соединение работает нормальноисточник
Проверьте, можете ли вы запросить у других приложений (например, Safari). Если нет, может быть что-то на вашем компьютере. В моем случае у меня была проблема с Avast Antivirus, который блокировал мой запрос на симуляторы (не спрашивайте меня, почему).
источник
Перезагрузка компьютера исправила проблему для меня с Xcode9.1. Я перезапустил симулятор и Xcode, он не работает.
источник
Я столкнулся с той же проблемой, я включил Network Link Conditioner для медленного тестирования сети для приложения. Это создавало эту ошибку несколько раз, когда я ее отключил
Settings > Developer > Network Link Conditioner
, это решило мою проблему.Надеюсь, это поможет кому-то.
источник
Вдобавок ко всем ответам я нашел одно хорошее решение. На самом деле проблема, связанная с ошибкой сетевого подключения для iOS 12.0, заключается в том, что в iOS 12.0 есть ошибка. И оно еще не решено. Я прошел через сообщество git hub для решения проблемы AFNetworking, когда приложение пришло из фона и пытается выполнить сетевой вызов и не может установить соединение. Я потратил 3 дня на это и пробовал много вещей, чтобы найти причину этого и ничего не нашел. Наконец я получил немного света в темноте, когда я красный этот блог https://github.com/AFNetworking/AFNetworking/issues/4279
Это говорит об ошибке в iOS 12. По сути, вы не можете ожидать, что сетевой вызов когда-либо завершится, если приложение не на переднем плане. И из-за этой ошибки сетевые вызовы сбрасываются, и мы получаем сетевые сбои в журналах.
Мое лучшее предложение для вас - предоставить некоторую задержку, когда ваше приложение переходит от фона к переднему плану и происходит сетевой вызов. Выполните этот сетевой вызов в асинхронной отправке с некоторой задержкой. Вы никогда не получите сброса сетевого вызова или потери соединения.
Не ждите, пока Apple разрешит эту проблему для iOS 12, поскольку ее еще предстоит исправить. Вы можете использовать этот обходной путь, предоставив некоторую задержку для вашего сетевого запроса, являющегося его NSURLConnection, NSURLSession или AFNetworking или ALAMOFIRE. Ура :)
источник
В моем случае это было потому, что я подключался к HTTP, и он работал по HTTPS.
источник
У меня была эта проблема по следующей причине.
TLDR: проверьте, отправляете ли вы
GET
запрос, который должен отправлять параметры по URL, а не поNSURLRequest's HTTBody
свойству.==================================================
Я установил сетевую абстракцию в своем приложении, и она работала довольно хорошо для всех моих запросов.
Я добавил новый запрос в другой веб-сервис (не мой), и он начал выдавать мне эту ошибку.
Я пошел на игровую площадку и начал с нуля строить запрос по голым костям, и это сработало. Поэтому я начал приближаться к своей абстракции, пока не нашел причину.
В моей реализации абстракции была ошибка: я отправлял запрос, который должен был отправить параметры, закодированные в URL, и я также заполнял
NSURLRequest's HTTBody
свойство параметрами запроса. Как только я удалил,HTTPBody
все заработало.источник
Я получал эту ошибку, а также замечал, что приложение Почтальон тоже падало, но работало в приложении Advanced Rest Client (ARC) и работало в Android. Поэтому мне пришлось установить Чарльза для отладки связи, и я заметил, что код ответа был -1. Проблема была в том, что программист REST забыл вернуть код ответа 200.
Я надеюсь, что это поможет другим разработчикам.
источник
Всякий раз, когда появляется ошибка -1005, необходимо снова вызвать API.
Вам нужно добавить свой код, чтобы снова вызвать функцию. Убедитесь, что вы вызывали метод один раз, иначе вызовите рекурсивный цикл.
источник
Я столкнулся с той же проблемой, когда звонил, используя сервер моей компании из приложения iOS 12 с физического устройства. Проблема заключалась в том, что жесткий диск сервера был заполнен. Освобождение места на сервере решило проблему.
Я обнаружил ту же ошибку в другой ситуации, которую я считаю из-за тайм-аута, который нельзя параметризировать через стандартный сетевой API, предоставляемый Apple (
URLSession.timeoutIntervalForRequest
иURLSession.timeoutIntervalForResource
). Даже там .. заставил сервер ответить быстрее, решил проблемуисточник