WordPress REST API 401 인증 실패는 대부분 “요청은 도착했지만 로그인 정보가 유효하지 않다”는 뜻입니다. n8n, Zapier, Make, 자체 Node.js 스크립트, Claude Code로 만든 자동 포스팅 도구를 워드프레스에 붙일 때 가장 먼저 확인할 것은 인증 방식, 권한, 보안 플러그인, 서버 헤더 전달입니다.
Postman 또는 curl로 인증 기준값을 먼저 만든 뒤, 자동화 도구 설정을 하나씩 비교해보세요.
제가 AI 에이전트로 글 초안을 만들고 WordPress REST API로 임시글을 생성하는 워크플로를 구성할 때도, 코드보다 서버 설정에서 더 자주 막혔습니다. 아래 순서대로 보면 원인을 빠르게 좁힐 수 있습니다.
먼저 10분 점검부터 하세요
Postman 또는 curl로 인증 요청이 통과하는지 확인하면 n8n·Zapier 설정 문제인지, 워드프레스 서버 문제인지 바로 갈립니다.
401이 날 때 가장 먼저 볼 순서
1. 인증 방식이 현재 워드프레스와 맞는지 확인
워드프레스 기본 계정 비밀번호를 REST API에 그대로 넣으면 실패하는 경우가 많습니다. 보통은 Application Passwords를 써야 합니다. 관리자 화면에서 사용자 프로필로 들어가 애플리케이션 비밀번호를 생성한 뒤, 사용자명과 생성된 비밀번호를 Basic Auth로 전달합니다.
예를 들어 curl 테스트는 이렇게 합니다.
curl -u "admin:xxxx xxxx xxxx xxxx xxxx xxxx" \
https://example.com/wp-json/wp/v2/posts여기서 비밀번호에 공백이 포함되어 있어도 그대로 복사해야 합니다. 자동화 도구 입력칸에서 공백이 잘리는 경우가 있으니, Postman에서 먼저 검증해보면 좋습니다.
2. 사용자 권한과 엔드포인트를 분리해서 본다
GET 요청은 되는데 POST 요청만 401 또는 403으로 실패한다면 인증 자체보다 권한 문제일 가능성이 큽니다. 글 생성은 최소 작성자 이상의 권한이 필요하고, 커스텀 포스트 타입이나 미디어 업로드는 별도 권한·플러그인 설정이 영향을 줍니다.
AI 자동 게시 파이프라인을 만들 때는 처음부터 관리자 계정을 연결하기보다, “자동화 전용 사용자”를 만들고 필요한 권한만 부여하는 편이 안전합니다. 계정이 꼬였을 때도 비밀번호만 폐기하면 됩니다.
3. 보안 플러그인과 방화벽이 Authorization 헤더를 막는지 확인
Wordfence, iThemes Security, LiteSpeed Security, Cloudflare WAF 같은 도구가 REST API 요청을 차단할 수 있습니다. 특히 외부 자동화 서버에서 오는 요청은 봇처럼 보이기 쉽습니다.
이때는 플러그인을 전부 끄기보다, 먼저 로그를 봅니다. Cloudflare라면 Security Events, Wordfence라면 Live Traffic 또는 Firewall 로그에서 /wp-json/ 요청이 막혔는지 확인하세요.
도구별로 어디를 의심해야 할까
| 연결 도구 | 자주 나는 원인 | 먼저 해볼 테스트 |
|---|---|---|
| Postman | Basic Auth 입력 오류, Application Password 공백 누락 | GET /wp-json/wp/v2/users/me 호출 |
| n8n | Credential에 일반 비밀번호 입력, 헤더 누락 | HTTP Request 노드에서 Authorization 직접 지정 |
| Zapier / Make | 워드프레스 플러그인 인증 방식과 충돌 | 공식 WordPress 앱 대신 Webhook으로 단순 호출 |
| 자체 코드 / Claude Code 생성 스크립트 | Base64 인코딩 오류, HTTPS 리다이렉트 중 헤더 손실 | curl 성공값과 코드의 헤더를 비교 |
| Cloudflare 사용 사이트 | WAF, Bot Fight Mode, 국가 차단 | 보안 이벤트에서 wp-json 차단 기록 확인 |
제가 실제로 자주 쓰는 확인 흐름
자동 글 발행 테스트를 할 때 저는 바로 n8n 시나리오를 고치지 않습니다. 먼저 Postman으로 /wp-json/wp/v2/users/me를 호출합니다. 이 엔드포인트는 “내 인증이 먹혔는지” 확인하기 좋습니다.
가상의 예로, Claude Code가 만든 Node.js 스크립트에서 글 생성이 계속 실패한다고 해보겠습니다. Postman에서는 성공하는데 스크립트만 실패한다면 워드프레스 문제가 아니라 코드의 Authorization 헤더 생성이 원인일 가능성이 큽니다. 반대로 Postman도 실패하면 Application Password, 서버 헤더 전달, 보안 플러그인 순서로 내려가면 됩니다.
Apache·Nginx에서 Authorization 헤더가 사라지는 경우
호스팅 환경에 따라 PHP로 Authorization 헤더가 전달되지 않을 수 있습니다. Apache라면 .htaccess에 아래 설정이 필요한 경우가 있습니다.
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]Nginx는 서버 블록이나 PHP-FPM 설정에서 헤더 전달을 확인해야 합니다. 이 부분은 호스팅사마다 다르므로, 공유호스팅이라면 고객센터에 “WordPress REST API Basic Auth의 Authorization 헤더가 PHP로 전달되는지”라고 구체적으로 문의하는 것이 빠릅니다.
이런 상황이면 이렇게 선택하세요
개발자·빌더라면
Postman과 curl로 먼저 최소 요청을 고정하세요. 그 다음 n8n, Make, 자체 스크립트에 같은 헤더를 옮기는 방식이 디버깅 시간을 줄입니다. Claude Code나 Cursor에게 코드를 수정시킬 때도 “curl은 성공한다”는 기준값이 있으면 훨씬 정확해집니다.
노코드 자동화 사용자라면
n8n이나 Zapier에서 워드프레스 계정을 다시 연결하기 전에 Application Password를 새로 발급하세요. 이미 실패한 인증정보를 계속 수정하는 것보다 새 credential을 만드는 편이 덜 헷갈립니다.
흔한 실수 하나: 401과 403을 같은 문제로 보는 것
401은 대체로 “인증 실패”, 403은 “인증은 됐지만 권한 부족 또는 차단”에 가깝습니다. 물론 플러그인에 따라 응답 코드가 섞일 수 있지만, 둘을 구분하면 점검 범위가 줄어듭니다.
또 하나는 관리자 비밀번호를 외부 자동화에 넣는 것입니다. 테스트는 쉬워 보여도 나중에 계정 관리가 어려워집니다. 자동화 전용 계정과 Application Password 조합을 기본값으로 두는 것을 권합니다.
FAQ
Application Password를 만들었는데도 401이 납니다. 왜 그럴까요?
가장 흔한 원인은 사용자명 오타, 비밀번호 공백 누락, HTTPS 리다이렉트 중 Authorization 헤더 손실입니다. 먼저 curl로 직접 호출하고, 성공하면 자동화 도구 설정을 비교하세요.
REST API를 막아둔 보안 플러그인은 꺼야 하나요?
전체 비활성화보다 로그 확인이 먼저입니다. /wp-json/ 경로만 예외 처리하거나, 자동화 서버 IP를 허용 목록에 넣는 방식이 더 안전합니다.
JWT 플러그인을 꼭 써야 하나요?
단순 글 작성 자동화라면 Application Password로 충분한 경우가 많습니다. 모바일 앱, 외부 사용자 로그인, 토큰 만료 관리가 필요할 때 JWT를 검토하세요.
바로 할 다음 행동
지금 할 일은 하나입니다. Postman 또는 curl로 /wp-json/wp/v2/users/me를 호출해 인증 통과 여부를 먼저 확인하세요. 성공하면 n8n·Zapier·코드의 헤더 문제로 좁히고, 실패하면 워드프레스 사용자·서버·보안 플러그인 순서로 보면 됩니다.
관련 링크
- ai api 비용 비교: 사이드프로젝트 챗봇 만들 때 실제로 갈리는 지점
- AutoWP 개발기 — OpenAI로 WordPress 콘텐츠 파이프라인을 만들고 사람이 검수하는 반자동 시스템
- openai api 비용 절감 방법: 작은 SaaS에서 먼저 손댄 7가지 설정
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
