안녕하세요
증상을 보면 `/webhwpctrl/save` 엔드포인트까지는 요청이 들어왔는데 `result: false`, `resultCode: 0`으로 실패하고 있습니다.
리버스 프록시 환경에서 HWPX 저장 시 자주 발생하는 패턴인데, 원인 가능성이 높은 순서로 정리합니다.
1. 세션/쿠키 문제
가장 흔한 원인입니다. payload의 `id` 값(`2D845E17-4B2D-4BAD-A460-…`)이 기안기 서버의 세션과 매핑되는데, 리버스 프록시를 거치면서 쿠키가 제대로 전달되지 않으면 서버가 세션을 찾지 못해 저장에 실패합니다.
nginx 기준으로 아래 헤더 전달 설정이 빠져 있는지 확인하세요.
location /webhwpctrl/ {
proxy_pass http://기안기설치ip/webhwpctrl/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cookie_domain 기안기설치ip 회사도메인;
proxy_cookie_path / /;
}
`proxy_cookie_domain` 설정이 없으면 기안기 서버가 Set-Cookie할 때 도메인이 내부 IP로 박혀서 브라우저가 쿠키를 버립니다.
2. 요청 바디 크기 제한
HWPX 포맷은 바이너리를 multipart로 올리기 때문에 데이터가 큽니다. nginx 기본 `client_max_body_size`는 1MB라서 문서 크기에 따라 413으로 잘릴 수 있습니다. 그런데 `resultCode: 0`이면 413이 아닌 기안기 서버 자체에서 내려주는 실패 응답이므로, 이건 2순위 확인 사항입니다.
client_max_body_size 50m;
3. duhwp.HwpCtrl vs HwpCtrl 호출 경로
질문에서 `duhwp.HwpCtrl.GetTextFile(“HWPX”, “”, function(res) {…})` 형태로 호출하고 있는데, `hwpctrlframe.html` 안의 `HwpCtrl`과 외부 페이지의 `duhwp.HwpCtrl`이 동일한 인스턴스를 참조하고 있는지 확인이 필요합니다.
`GetTextFile`은 비동기 콜백 방식으로 내부적으로 `/webhwpctrl/save`를 호출하는데, 이 요청이 iframe 기준 origin에서 발생합니다. 즉, iframe의 `src`가 `http://기안기설치ip/webhwpctrl/hwpctrlframe.html\`로 직접 설정되어 있으면 리버스 프록시를 우회해서 내부 IP로 직접 요청이 나가고, 그 응답의 쿠키/세션이 외부 도메인 세션과 달라 실패할 수 있습니다.
iframe src를 반드시 `http://회사도메인/webhwpctrl/hwpctrlframe.html\`로 설정해서 모든 요청이 리버스 프록시를 통하도록 맞춰야 합니다.
확인 순서 요약
1. 브라우저 네트워크 탭에서 /webhwpctrl/save 요청의 쿠키 헤더 확인
2. iframe src가 회사도메인 기준인지 확인
3. nginx proxy_cookie_domain 설정 확인
4. 기안기 서버 측 로그에서 세션 조회 실패 여부 확인
`resultCode: 0`이면 기안기 서버가 응답은 주고 있으니 네트워크 차단 문제는 아닙니다. 세션 불일치 가능성이 가장 높습니다.
감사합니다.