--- title: "401 Unauthorized в n8n: credentials и OAuth — Nodbot" source_url: "https://nodbot.ru/errors/401-unauthorized/" canonical_url: "https://nodbot.ru/errors/401-unauthorized/" language: "ru" content_type: "TroubleshootingGuide" section: "errors" generated_at: "2026-05-30" word_count_source: 967 --- # 401 Unauthorized в n8n: credentials и OAuth OAuth ## AI summary Как исправить 401 Unauthorized в n8n: неверный API key, Bearer token, OAuth scopes, Basic Auth, headers, credentials и проверка HTTP Request. ## Best used for Страница объясняет «401 Unauthorized в n8n: credentials и OAuth — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Пошаговая проверка - Bearer token - OAuth-проблемы - Где искать ошибку в n8n - Связанные статьи - Диагностика по шагам: как не лечить симптом вслепую - Проверка за 7 минут - Правильный порядок исправления ## Source outline # 401 Unauthorized в n8n: credentials и OAuth OAuth Обновлено: 2026-05-29 401 Unauthorized означает, что внешний сервис не принял авторизацию. Запрос дошёл до API, но credentials, token, header или scope не подходят. В отличие от 403, здесь чаще проблема именно в идентификации запроса. ## Пошаговая проверка - Убедитесь, что в ноде выбраны правильные credentials. - Проверьте, не истёк ли OAuth token и есть ли refresh. - Сравните header авторизации с документацией API. - Проверьте scope/permissions приложения. - Повторите минимальный запрос в HTTP Request без лишнего body. ## Bearer token Для многих API header должен выглядеть так: Authorization: Bearer TOKEN . Частая ошибка — вставить только token туда, где нужен полный header, или наоборот продублировать слово Bearer. ``` Authorization: Bearer {{ $credentials.apiKey }} Content-Type: application/json ``` ## OAuth-проблемы - Симптом | Что проверить - Работало, потом сломалось | Refresh token, срок действия, права приложения - Нужная операция не разрешена | Scopes и permissions - Credentials созданы не тем аккаунтом | Аккаунт владельца документа, бота или workspace - API key принят в одном endpoint, но не в другом | Разные продукты или разные base URL ## Где искать ошибку в n8n Откройте execution, проблемную ноду и вкладку с request/response. Нужны status code, response body и headers. Не копируйте секреты в публичные места: маскируйте token и ключи. ## Связанные статьи Для универсальной диагностики API смотрите HTTP Request . Для OpenAI — OpenAI , для Telegram — Telegram , для Google Sheets — Google Sheets . ## Диагностика по шагам: как не лечить симптом вслепую Проблему 401 Unauthorized в n8n: credentials и OAuth OAuth лучше разбирать как incident, а не как случайную ошибку в одной ноде. Сначала соберите доказательства, затем меняйте настройки workflow. ### Проверка за 7 минут - Откройте последний failed execution и сравните его с последним successful execution того же workflow. - Зафиксируйте входной item: сколько items пришло, какие поля отсутствуют, есть ли binary data. - Проверьте credentials отдельно: токен, scopes, refresh, базовый URL, права пользователя. - Повторите запрос из HTTP Request через curl/Postman с теми же headers и body. - Посмотрите, не сработали ли rate limits, timeout, proxy, SSL или блокировка по IP. - Если ошибка плавающая, добавьте временный лог в безопасное хранилище: execution_id, event_id, status_code, краткое тело ответа. ### Правильный порядок исправления - Шаг | Что менять | Когда откатывать - 1 | валидация входного payload | если ошибка воспроизводится на валидных данных - 2 | credentials или scopes | если запрос падает вне n8n тем же статусом - 3 | retry/wait/backoff | если проблема связана с 429/5xx/timeout - 4 | структура workflow | если item count меняется после Merge/Split/Code ### После фикса - запустите старый failed payload повторно на тестовой копии workflow; - проверьте, что ошибка не превратилась в silent failure; - добавьте ссылку на эту страницу в error workflow или alert-сообщение; - для повторяющихся инцидентов используйте workflow уведомлений об ошибках . ## Глубокая диагностика: что проверить до изменения workflow Для проблемы 401 Unauthorized в n8n: credentials и OAuth OAuth сначала зафиксируйте факты, а не меняйте ноды наугад. Откройте failed execution, найдите первую ноду, где входные данные ещё корректны, а выход уже отличается от ожидаемого. Сравните не только текст ошибки, но и item count, полный JSON, headers, status code, binary data и время выполнения. - Запишите слой сбоя: данные, авторизация, API, нода, очередь, база, reverse proxy или AI-слой. - Соберите минимальный воспроизводимый пример на одном item и отдельно прогоните batch из 3–5 items. - Проверьте, не маскирует ли retry исходную ошибку: в истории executions смотрите первый, а не последний сбой. - Если задействован oauth, сравните реальный request/response из n8n с рабочим запросом вне n8n, скрыв секреты. - После исправления сохраните пример плохого payload в тестовом workflow или в runbook, чтобы не терять контекст. ## Решение без побочных эффектов Правка должна быть минимальной: исправляйте только тот слой, где доказана причина. Для 401 Unauthorized в n8n: credentials и OAuth OAuth опасно одновременно менять credentials, mapping, retry и бизнес-логику: после этого сложно понять, что действительно помогло. - Шаг | Что сделать | Как понять, что помогло - 1 | Изолировать проблемный item или request | ошибка повторяется на одном и том же входе - 2 | Нормализовать поля перед проблемной нодой | вход имеет стабильную схему и обязательные поля - 3 | Добавить явную ветку ошибки | workflow не теряет данные и пишет причину сбоя - 4 | Проверить retry/idempotency | повтор не создаёт дублей и не ломает внешний сервис ## Контрольный список после исправления - один успешный и один проблемный пример проходят предсказуемо - в execution видно, какие данные ушли дальше по цепочке - ошибка больше не скрывается за общим сообщением вроде “workflow failed” - alert отправляется владельцу workflow с ID execution и короткой причиной - для внешних записей есть ключ идемпотентности: order_id, event_id, email+date или payload_hash ## Ручная диагностика перед исправлением Перед тем как менять настройки по теме «401 Unauthorized в n8n», зафиксируйте не только текст ошибки, но и последний успешный запуск. Для n8n это критично: один и тот же симптом может появиться из-за credentials, изменения payload, лимита API, обновления версии или инфраструктурного сбоя. Рабочий порядок: изолируйте один execution, сохраните входной item без секретов, проверьте branch с ошибкой и только потом меняйте workflow. Главный риск — исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении. - Слой | Что зафиксировать | Зачем - Вход | payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом | позволяет повторить проблему без доступа к production-секретам - Контроль | error_count_by_node, retry_count, first_failed_execution, last_successful_execution, affected_workflows | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «401 Unauthorized в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "execution_id": "exec_...", "workflow_id": "wf_...", "node_name": "node_with_symptom", "error_message": "точный текст ошибки без токенов", "input_item_id": "external_or_dedupe_id", "last_successful_run": "timestamp", "changed_before_error": ["credentials", "payload", "version", "env"] } ``` ### Критерий готовности - точный текст ошибки сохранён без токенов и персональных данных - понятно, какая нода упала первой, а какие ошибки были следствием - есть минимальный воспроизводимый workflow или тестовый execution - после исправления проверены retry, error branch и последний успешный сценарий ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.