YML-фид не загружается: причины ошибок 403, 404, 500, редиректов и таймаутов

Ситуация неприятная: вы открываете ссылку на YML-фид в браузере, файл виден, XML выглядит целым, но внешняя площадка пишет, что не может его скачать. Значит, проверять нужно не только содержимое фида, а весь сетевой путь. У браузера и робота разные условия запроса: заголовки, IP-адрес, cookie, поддержка редиректов, лимиты времени и реакция защиты сервера.

Короткий путь такой: URL из кабинета площадки попадает к роботу, робот делает HTTP-запрос к вашему серверу, скачивает ответ, проверяет статус и заголовки, затем передает тело ответа XML-парсеру. Ошибка может возникнуть на любом участке: адрес ведет не туда, сервер запрещает робота, TLS-соединение не устанавливается, редирект уходит в HTML-страницу, генератор фида отвечает слишком долго или вместо XML возвращает страницу входа.

Как запрос доходит до фида

В кабинете получателя обычно хранится обычная ссылка: например, https://example.test/feed.xml. Когда приходит время импорта, площадка запускает серверный запрос. Он идет через DNS, CDN или балансировщик, веб-сервер и приложение, которое отдает готовый файл или генерирует его на лету. После этого площадка смотрит HTTP-статус, размер, тип контента, цепочку редиректов и только потом разбирает XML.

Если импорт падает до разбора XML, статья о типичных ошибках YML-фида пока не поможет: парсер еще не получил документ. Сначала нужно доказать, что внешний клиент стабильно скачивает именно XML. Если подозрение в старой копии, используйте отдельную диагностику того, почему YML-фид не обновляется; здесь разбираем именно недоступность или неправильную отдачу по URL.

Для площадки важен не вид страницы в браузере, а итоговый HTTP-ответ, который можно скачать без ручного входа и интерактивной защиты.

Что означают HTTP-статусы

HTTP-статус — первый короткий ответ сервера о результате запроса. Он не заменяет проверку тела ответа, но быстро показывает, где копать: в адресе, правах доступа, лимитах, сервере или генераторе.

Статус нужно смотреть без догадок. Иногда браузер показывает красивую страницу с текстом ошибки, а в заголовках при этом стоит 200. Иногда наоборот: браузер следует редиректу, а площадка фиксирует первый 302 и считает ссылку неподходящей.

Почему браузер видит файл, а робот нет

Браузер почти всегда отправляет больше контекста. В нем могут быть cookie после входа в админку, заголовки языка, сохраненная сессия, поддержка JavaScript-проверки, доверенный домашний IP и кэш. Робот площадки приходит с другого адреса, другим User-Agent и без вашей авторизации.

Частые причины различий:

• WAF или CDN. Защита может считать неизвестный User-Agent подозрительным и отдавать 403 или HTML-челлендж вместо XML.
• IP-фильтры. Сервер разрешает ваш офисный IP, но закрыт для внешних дата-центров.
• Cookie и авторизация. В браузере вы уже вошли, а робот получает 401, 302 на логин или HTML-страницу входа.
• Временная ссылка. URL с коротким токеном работает несколько минут, а импорт запускается позже.
• http вместо https. Старый адрес может редиректить, блокироваться или вести на другую конфигурацию.
• Rate limits. Несколько повторных попыток подряд получают 429, хотя ручная проверка через минуту уже проходит.

Редиректы и финальный URL

Один аккуратный редирект с HTTP на HTTPS обычно не проблема, но длинные цепочки быстро ломают импорт. Риск появляется, когда /feed ведет на /login, мобильную страницу, HTML-прослойку CDN, другой домен или архивный файл. Еще один частый случай — редирект с URL без слеша на URL со слешем, где приложение вместо XML отдает страницу каталога.

Сверяйте три вещи: начальный URL в кабинете, список всех промежуточных ответов и финальный адрес после -L. Если финальный адрес отличается, передайте площадке сразу его. Чем меньше переходов между роботом и XML, тем меньше мест, где импорт может упасть.

SSL и TLS

HTTPS-адрес должен открываться не только в современном браузере, но и в серверном клиенте. Проверяйте срок сертификата, цепочку промежуточных сертификатов, соответствие домена и поддержку актуальных протоколов TLS. Самоподписанный сертификат, неполная цепочка или сертификат для другого домена могут выглядеть как «фид не загружается», хотя XML на сервере правильный.

Отдельно проверьте смешение протоколов. Если в кабинете указан http://, а сервер принудительно переводит на https://, убедитесь, что робот следует этому редиректу и попадает в тот же файл. Если есть выбор, храните в кабинете конечный HTTPS-URL без лишнего промежуточного шага.

Таймауты, размер и обрывы соединения

Большой или динамический фид может открываться в браузере, потому что человек готов подождать, а импорт ограничен таймаутом. Проблема усиливается, если файл генерируется во время запроса: база занята, PHP-процесс упирается в лимит времени, прокси закрывает соединение, а площадка получает обрезанный XML или 504.

Надежная схема — генерировать фид заранее в файл, проверять его локально, затем публиковать готовую копию. Если генерация по запросу уже работает и каталог небольшой, оставьте ее. Но при регулярных 500/502/503/504, скачках времени ответа или обрывах соединения дешевле убрать динамику с публичного URL, чем увеличивать таймауты по всей цепочке.

Отдельно смотрите, в какой момент соединение закрывается. Если размер скачанной копии каждый раз разный, сервер, прокси или генератор может отдавать частичный файл. Если размер стабилен, но время близко к лимиту, импорт будет зависеть от нагрузки. Если первая проверка после очистки кеша медленная, а следующие быстрые, проблема не в XML, а в прогреве генерации или кеша. Эти признаки лучше записывать числами: время ответа, размер файла, код статуса и время генерации в логах.

Когда 200 не означает XML

Самый обманчивый случай — сервер возвращает HTTP 200, но тело ответа не является YML. Это может быть HTML-страница входа, сообщение WAF, «файл готовится», страница ошибки приложения, JSON с диагностикой или пустой шаблон. Браузер покажет страницу, а площадка попытается разобрать ее как XML и получит ошибку.

Проверяйте Content-Type, первые байты файла и наличие корневого элемента <yml_catalog>. Для YML нормально использовать application/xml, text/xml или другой ожидаемый XML-тип. Один только заголовок не гарантирует правильный документ, поэтому после скачивания нужен XML-разбор. Если хотите освежить саму структуру, есть отдельное руководство что такое YML-фид и как он устроен.

Безопасные curl-команды

Команды ниже не отправляют пароли и не меняют данные. Подставьте публичный адрес вместо https://example.test/feed.xml. Если результат нужно переслать разработчику или хостингу, сначала уберите токены и приватные параметры из URL.

curl -sS -L -o /dev/null \
  -w 'HTTP %{http_code}\nURL %{url_effective}\nTime %{time_total}s\n' \
  https://example.test/feed.xml

Эта проверка следует редиректам, не сохраняет тело ответа и показывает итоговый статус, конечный URL и время скачивания. Если вместо 200 видны 403, 404, 429 или 5xx, XML пока проверять рано.

curl -sSIL https://example.test/feed.xml

Так видно цепочку заголовков: статусы, Location, Content-Type, Content-Length, кеширование и признаки CDN. Это быстрая предварительная проверка через HEAD-запрос. Настройки HEAD и GET иногда различаются, поэтому результат обязательно подтвердите обычным скачиванием.

curl -sS -L -A 'FeedChecker/1.0' \
  https://example.test/feed.xml -o feed.xml
file feed.xml
head -c 200 feed.xml

Эта команда сохраняет ответ с простым небраузерным User-Agent, но не имитирует конкретную площадку. file и первые байты помогают быстро увидеть HTML вместо XML. Не публикуйте сохраненный файл, если внутри есть закрытые товары или цены.

curl -sS -L --max-time 30 \
  https://example.test/feed.xml -o feed.xml
xmllint --noout feed.xml

Здесь важен лимит времени. Если файл не успевает скачаться за разумный срок или xmllint видит обрыв, ищите проблему в генерации, размере, прокси или соединении. При отсутствии xmllint используйте штатный XML-парсер проекта или валидатор.

Пошаговая диагностика

1. Скопируйте URL из кабинета площадки. Не берите похожую ссылку из админки или браузерной истории.
2. Проверьте статус без скачивания тела. Нужен 200 или понятный короткий редирект к конечному XML.
3. Посмотрите Content-Type. HTML, JSON и пустой ответ означают, что робот получает не фид.
4. Разберите редиректы. Финальный URL должен быть тем адресом, который вы готовы отдавать внешней системе.
5. Скачайте файл как внешний клиент. Сравните размер, первые строки и контрольный фрагмент с ожидаемым фидом.
6. Проверьте содержимое. Найдите <yml_catalog>, <shop>, несколько <offer> и завершение документа.
7. Повторите запрос. Если один раз 200, а второй раз 429 или 504, проблема в лимитах или нестабильной генерации.
8. Откройте логи. Смотрите одно и то же время в access log, error log, логах приложения, CDN и очереди генерации.

Если на каком-то шаге результат отличается от ожидаемого, чините найденный участок и только потом идите дальше. Нет смысла спорить о требованиях площадки, пока сервер вместо XML отдает 403 или HTML-страницу.

Что проверить за 10 минут

• URL в кабинете совпадает с публичным URL фида и не требует входа.
• Запрос без cookie и браузерной сессии возвращает HTTP 200.
• Финальный URL после редиректов ведет на XML, а не на страницу входа или витрину.
• Сервер не блокирует запросы по User-Agent, IP-адресу или частоте.
• HTTPS-сертификат действителен, цепочка полная, домен совпадает.
• Content-Type и первые байты ответа похожи на XML.
• Файл скачивается полностью за разумное время и не обрывается.
• Размер и контрольный фрагмент совпадают с ожидаемой свежей версией.
• Повторная проверка не получает 429, 500, 502, 503 или 504.
• В логах есть запрос робота и понятный ответ сервера в то же время.

Вывод

Ошибка «YML-фид не загружается» почти всегда проверяется быстрее, если разделить ее на четыре слоя: адрес, HTTP-ответ, скачивание и XML-содержимое. Браузерная проверка полезна только как первый сигнал. Решение принимайте по фактическому статусу, редиректам, заголовкам, времени скачивания, сохраненной копии и логам.

Когда URL стабильно отдает 200, скачивается без таймаута и содержит настоящий XML, переходите к проверке структуры и товарных данных. Проверьте YML-фид по URL в ФидСтороже: сервис поможет быстро увидеть, дошел ли документ до разбора и какие ошибки остались уже внутри файла.