WebDAV 연결을 붙였는데 클라이언트에서 PROPFIND 401, 405, 207 같은 응답이 보이면 처음엔 다 비슷한 오류처럼 느껴진다. 그런데 이 셋은 의미가 완전히 다르다. 401은 인증 축, 405는 메서드 지원 축, 207은 오히려 성공 또는 부분 성공 축이다. 이 차이를 먼저 자르면 복구 속도가 훨씬 빨라진다.
공식 RFC 4918는 WebDAV 서버라면 PROPFIND를 지원해야 하고, 207 Multi-Status는 여러 리소스의 상태를 한 번에 담는 응답이라고 설명한다. 또 NGINX 공식 ngx_http_dav_module 문서는 이 모듈이 PUT, DELETE, MKCOL, COPY, MOVE를 처리하며, 추가 WebDAV 메서드가 필요한 클라이언트는 동작하지 않을 수 있다고 적고 있다. 즉 PROPFIND 405는 단순 버그가 아니라, 지금 붙은 서버가 완전한 WebDAV 서버가 아닌 상황일 수 있다.
WsgiDAV 공식 README와 설정 문서도 wsgidav --host=0.0.0.0 --port=8080 --root=/tmp --auth=anonymous 같은 CLI 실행과 provider_mapping, 설정 파일 사용 방식을 보여준다. 그래서 Python 기반 WebDAV 서버라면 인증 설정, 공유 경로 매핑, 리버스 프록시 라우팅을 같이 봐야 한다.
이 문서는 생성형 AI를 활용해 초안을 만들고, RFC 4918·NGINX 공식 문서·WsgiDAV 공식 문서를 다시 확인해 정리했습니다.
flowchart TD A[PROPFIND 응답 확인] --> B{상태코드가?} B -->|401| C[인증 정보와 auth 설정 확인] B -->|405| D[서버가 PROPFIND를 지원하는지 확인] B -->|207| E[XML 본문과 href/status 확인] C --> F[계정 비밀번호 공유경로 재점검] D --> G[NGINX DAV 모듈만 쓰는지 upstream 점검] E --> H[성공인지 부분실패인지 분리] F --> I[curl로 재검증] G --> I H --> I
칠판 치트시트
401은 인증 실패부터 본다405는 서버가PROPFIND를 진짜 지원하는지 본다207은 에러가 아니라 멀티 상태 응답일 수 있다- WebDAV는 URL 경로와 공유 매핑이 틀리면 겉보기만 멀쩡할 수 있다
- 복구는
curl -X PROPFIND로 직접 재현해 보는 편이 가장 빠르다
이런 증상이면 이 문서가 맞다
- Obsidian, WebDAV 클라이언트, 파일 앱에서
PROPFIND 401 Unauthorized가 반복된다. - 브라우저에선 주소가 열리는데 WebDAV 클라이언트는
405 Method Not Allowed를 띄운다. 207 Multi-Status가 보여서 에러로 오해하고 있다.- 리버스 프록시 뒤에 WebDAV를 붙였는데 폴더 목록이 안 보이거나 빈 응답처럼 느껴진다.
먼저 알아야 할 의미 3가지
1) PROPFIND는 WebDAV의 핵심 메서드다
RFC 4918의 PROPFIND Method 섹션은 WebDAV 서버라면 PROPFIND를 지원해야 하고, Depth 헤더와 함께 리소스 속성이나 컬렉션 내부 리소스를 조회할 수 있다고 설명한다. 즉 WebDAV 클라이언트가 연결 직후 PROPFIND를 보내는 건 이상한 동작이 아니라 정상 흐름이다.
curl -u USER:PASS -X PROPFIND https://example.com/remote.php/webdav/ -H 'Depth: 0' -i여기서 Depth: 0은 현재 리소스만, Depth: 1은 하위까지 포함해 보는 식이다. RFC는 Depth 헤더가 없으면 infinity처럼 처리할 수 있다고 설명하므로, 서버에 따라 응답이 무겁거나 느려질 수 있다.
2) 207 Multi-Status는 성공일 수 있다
RFC 4918의 207 Multi-Status와 Multi-Status Response 섹션이 핵심이다. 207은 여러 리소스의 상태를 XML 본문에 담는 응답이다. 그래서 숫자만 보고 실패로 단정하면 안 된다. 실제 판단은 본문의 multistatus, href, status 요소를 같이 봐야 한다.
즉 207은 아래처럼 해석하는 편이 맞다.
- 서버가 WebDAV 요청을 이해했다.
- 여러 리소스 결과를 한 번에 주고 있다.
- 일부 항목은 성공, 일부는 실패일 수도 있다.
그래서 클라이언트가 207을 보여줘도, 폴더 접근 자체는 정상인 경우가 적지 않다.
3) 405는 WebDAV 서버가 아닐 가능성을 먼저 본다
NGINX 공식 ngx_http_dav_module 문서는 이 모듈이 PUT, DELETE, MKCOL, COPY, MOVE를 처리한다고 적고, 추가 WebDAV 메서드가 필요한 클라이언트는 동작하지 않을 수 있다고 분명히 적고 있다. 즉 NGINX DAV 모듈만으로 WebDAV 클라이언트를 받으면 PROPFIND 단계에서 막힐 수 있다.
이 장면이 많이 헷갈린다. 브라우저로는 URL이 열리니까 서버가 정상처럼 보이는데, 실제로는 읽기/속성 조회용 WebDAV 메서드가 빠져 있는 상태일 수 있다.
가장 빠른 확인 순서
1) 401이면 인증과 공유 경로를 먼저 자른다
WsgiDAV 공식 설정 문서는 CLI에서 --auth=anonymous 같은 옵션을 줄 수 있고, 더 많은 설정은 wsgidav.yaml이나 wsgidav.json에서 다룬다고 설명한다. 또 provider_mapping으로 어떤 경로를 실제 공유 루트에 매핑할지 정의한다.
그래서 401이면 아래 순서가 빠르다.
- 클라이언트 계정과 비밀번호가 맞는지 본다.
- 실제 WebDAV 공유 경로가 맞는지 본다.
- 서버가 anonymous인지 basic/digest인지 인증 모드를 본다.
- 리버스 프록시가 Authorization 헤더를 깨지 않는지 본다.
작은 미니 사례로 보면 더 쉽다. 예를 들어 브라우저에서 기본 인증 팝업은 뜨는데 WebDAV 앱만 401이 난다면, 계정 오타보다 앱이 붙는 경로가 실제 공유 매핑과 다른 경우가 많다.
2) 405면 리버스 프록시와 실제 upstream을 확인한다
이 단계는 생각보다 중요하다. 405 Method Not Allowed는 URL이 열리지 않는 문제가 아니라, 그 URL이 PROPFIND를 처리할 수 없는 위치라는 뜻에 가깝다.
아래처럼 자르면 빠르다.
- 지금 붙은 서버가 완전한 WebDAV 서버인지 본다.
- NGINX DAV 모듈만 단독으로 쓰는지 본다.
- 리버스 프록시가 실제 WebDAV upstream이 아니라 정적 경로나 앱 메인 페이지로 보내고 있지 않은지 본다.
curl -X PROPFIND로 브라우저 말고 직접 메서드를 던져 본다.
curl -u USER:PASS -X PROPFIND https://example.com/dav/ -H 'Depth: 0' -i브라우저 GET은 되는데 PROPFIND만 405면, 거의 항상 경로 또는 서버 역할이 틀린 쪽을 먼저 봐야 한다.
3) 207이면 에러로 볼지 말지 XML 본문까지 본다
207은 숫자만 보면 낯설어서 에러처럼 느껴진다. 하지만 RFC 기준으로는 여러 리소스 상태를 묶어서 주는 정상적인 WebDAV 응답이다. 그래서 이 단계에서는 상태코드 숫자보다 XML 본문을 본다.
href가 내가 기대한 경로인지- 각
status가200 OK인지, 일부만404/403인지 Depth: 1에서 하위 항목이 어떻게 보이는지
예를 들어 루트는 207인데 폴더가 비어 보인다면, 실제론 인증이 아니라 잘못된 컬렉션 경로를 보고 있을 가능성이 있다.
자주 헷갈리는 장면 4가지
1) 브라우저에서는 열리는데 WebDAV 앱에서만 실패
이 경우는 GET과 PROPFIND 차이를 먼저 봐야 한다. 브라우저는 단순 GET으로 홈 화면을 보여줄 수 있지만, WebDAV 앱은 처음부터 PROPFIND를 보낸다. 그래서 브라우저가 열린다고 WebDAV가 정상인 것은 아니다.
2) 401이 비밀번호 문제라고만 생각함
비밀번호가 맞아도 공유 경로가 다르면 같은 증상이 난다. WsgiDAV처럼 provider_mapping이 있는 서버는 루트 URL과 실제 공유 URL이 다를 수 있다.
3) 405를 방화벽 문제로 오해함
방화벽 문제면 보통 연결 자체가 안 되거나 timeout이 난다. 405는 서버가 요청을 받았고, 그 메서드를 허용하지 않는다는 뜻에 더 가깝다.
4) 207을 오류라고 오해함
이건 WebDAV에서 아주 흔한 오해다. 207은 전체적으로 실패를 의미하는 코드가 아니라, 여러 리소스 결과를 묶어 주는 그릇이다. 그래서 XML 내부를 확인하기 전엔 실패라고 단정하면 안 된다.
가장 빠른 복구 순서
1) curl로 서버를 직접 찔러본다
클라이언트 앱을 잠시 빼고 curl -X PROPFIND로 재현하면 인증 문제인지, 메서드 문제인지 바로 갈린다.
2) 경로를 다시 자른다
루트 /, /dav/, /webdav/, /remote.php/webdav/처럼 제품마다 진입 경로가 다르다. 잘못된 경로에서는 401, 404, 405, 빈 207이 뒤섞여 보일 수 있다.
3) 서버 역할을 확인한다
NGINX DAV 모듈만 둔 것인지, WsgiDAV 같은 실제 WebDAV 서버를 뒤에 붙인 것인지 본다. 특히 리버스 프록시 앞단만 보고 있으면 PROPFIND 단계에서 바로 막힐 수 있다.
4) 인증 모드와 헤더 전달을 확인한다
기본 인증을 쓰는 경우 Authorization 헤더 전달이 끊기면 겉보기만 정상이고 앱에서는 계속 401이 난다. 리버스 프록시 경유라면 이 축도 같이 봐야 한다.
현장 미니 사례 3개
사례 A) Obsidian 계열 클라이언트에서 401 Unauthorized
- 상황: 같은 계정으로 브라우저 로그인은 되는데 앱만 실패
- 원인: 실제 공유 경로와 앱에 넣은 URL이 다름
- 복구: 공유 루트 URL 재확인, 계정 재입력,
curl -X PROPFIND로 재검증 - 검증: 같은 URL로
207또는200계열 WebDAV 응답이 오는지 확인
사례 B) 리버스 프록시 뒤에서 405 Method Not Allowed
- 상황: HTTPS는 열리는데 폴더 목록이 안 뜸
- 원인: NGINX DAV 모듈만 쓰거나, upstream이 정적 페이지로 연결됨
- 복구: 실제 WebDAV 서버 upstream 확인, PROPFIND 지원 경로로 수정
- 검증:
curl -X PROPFIND에서 더 이상405가 아닌지 확인
사례 C) 207 Multi-Status인데 사용자는 실패라고 오해
- 상황: 앱 로그에 207이 보여 불안해함
- 원인: WebDAV 특유의 멀티 상태 응답을 에러로 오해
- 복구: XML 본문에서
href와 개별status확인 - 검증: 요청 대상 리소스가 실제로 나열되는지 확인
운영자가 바로 판단하는 기준
| 상황 | 먼저 볼 것 | 이유 |
|---|---|---|
401 Unauthorized | 계정, 비밀번호, 공유 경로 | 인증과 경로가 가장 흔한 원인 |
405 Method Not Allowed | PROPFIND 지원 여부 | 서버가 완전한 WebDAV 서버가 아닐 수 있음 |
207 Multi-Status | XML 본문 | 숫자만으로 성공/실패를 단정할 수 없음 |
| 브라우저만 정상 | GET과 PROPFIND 차이 | WebDAV 앱은 다른 메서드를 쓴다 |
| 프록시 뒤에서만 실패 | upstream과 헤더 전달 | 실제 WebDAV 서버까지 요청이 안 갈 수 있음 |
검색형 FAQ
Q1. WebDAV에서 207이면 실패인가요?
아니다. RFC 4918 기준으로 207 Multi-Status는 여러 리소스 상태를 한 번에 담는 응답이다. XML 본문을 같이 봐야 한다.
Q2. 405면 서버가 죽은 건가요?
보통 그렇지 않다. 서버는 살아 있고, 그 경로가 PROPFIND를 허용하지 않거나 WebDAV 메서드를 완전히 지원하지 않는 경우가 많다.
Q3. 401은 무조건 비밀번호 문제인가요?
아니다. 계정 정보뿐 아니라 공유 URL, 인증 모드, 프록시 헤더 전달 문제도 같이 볼 필요가 있다.
Q4. 브라우저에서 열리면 WebDAV도 정상 아닌가요?
아니다. 브라우저는 주로 GET을 쓰지만, WebDAV 클라이언트는 처음부터 PROPFIND를 보낸다. GET 성공과 WebDAV 성공은 다를 수 있다.
다음 읽기
- 05. Obsidian EPERM 오류 해결
- 08. 시놀로지 Obsidian 원격 접속
- Obsidian 허브
- 25. Quartz에서 글 옮기고 지운 뒤 ENOENT로 다시 죽을 때
- Troubleshooting 허브
한 줄 결론
WebDAV에서 PROPFIND 401, 405, 207은 같은 에러 묶음이 아니다.
401은 인증, 405는 메서드 지원, 207은 멀티 상태 응답으로 자르면 복구 속도가 훨씬 빨라진다.
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.