비공개 게시글에서 첨부파일 주소를 복사했다고 가정해 보겠습니다. 글을 읽을 수 있는 계정 A에서는 파일이 열립니다. 글을 읽을 수 없는 계정 B에서도 같은 주소로 파일이 내려온다면, 게시글에 적용한 권한이 다운로드까지 이어지는지 살펴야 합니다. 확인할 곳은 두 군데입니다. 웹서버가 파일을 직접 내주는 경로와 게시판 앱이 다운로드 요청을 처리하는 경로입니다.공개 URL과 파일 저장 위치웹 루트는 웹서버가 URL을 실제 파일에 연결하는 기준 디렉터리입니다. 예를 들어 /var/www/site/public 아래의 uploads가 정적 파일로 공개돼 있다면, 브라우저가 /uploads/report.pdf를 요청했을 때 게시판 앱을 거치지 않고 파일을 받을 수 있습니다. 게시글 화면에서 첨부 링크를 감춰도 이미 ..

같은 게시판에 9MB짜리 파일은 올라가는데 10MB 파일은 업로드에 실패합니다. 이때 화면에 뜬 ‘첨부 실패’ 문구만으로는 어느 설정을 확인해서 수정해야될지 확인하기 어렵습니다. Nginx가 요청을 끊었을 수도 있고, PHP가 파일을 받지 못했거나 게시판이 자체 정책으로 거절했을 수도 있습니다. Nginx 뒤에서 PHP 게시판을 운영하는 구성을 예로 들어, 성공 요청과 실패 요청을 비교해 보겠습니다. 파일 크기와 요청 본문 크기 먼저 테스트 게시판에서 허용된 형식의 파일을 준비합니다. 같은 계정과 같은 업로드 경로에서 파일 한 개씩 보내고, 제목·본문 같은 입력값은 고정한 채 파일 크기만 바꿉니다. 브라우저 개발자 도구의 Network에서 첨부를 전송한 요청을 찾아 경로, 시..

서로 다른 네트워크에서 게시판에 접속했는데, 웹앱 로그에는 두 요청 모두 loopback ip인 127.0.0.1로 남습니다. 같은 서버의 Nginx가 요청을 앱에 넘길때 127.0.0.1은 앱에 실제로 연결한 상대의 주소입니다. 접속자 IP를 따로 기록하려면 Nginx가 어떤 값을 넘겼는지, 앱이 그 값을 어떤 조건에서 읽는지 확인해야 합니다.같은 요청, 두 로그의 IP테스트 요청 한 건을 보내고 요청 시각과 경로를 기준으로 Nginx 액세스 로그와 앱 로그를 맞춰 봅니다. Nginx의 로그 형식에 $remote_addr가 들어 있고 Nginx가 외부 연결을 직접 받는다면, 이 값은 Nginx에 연결한 상대의 주소입니다. 반면 앱의 req.socket.remoteAddress는 앱과 TCP 연결을 맺은..

웹을 운영하면서 게시판 메인은 열리는데 검색 결과 화면만 한참 뒤 504로 반환되는 케이스를 간혹 볼 수 있습니다. 같은 서버가 두 화면을 제공해도 검색 요청은 DB 쿼리나 WAS 단계에서 더 오래 걸릴 수 있습니다. 어느 구간이 느렸는지 확인하려면 Nginx가 응답을 기다린 구간과 게시판 앱이 실제로 요청을 처리한 시간을 따로 봐야 합니다. 여기서는 Nginx가 proxy_pass로 HTTP 앱 서버에 검색 요청을 넘기는 구성을 다룹니다. Nginx가 요청을 넘기는 뒤쪽 서버를 업스트림이라고 부릅니다. 오류 로그에 찍힌 대기 단계 504는 게이트웨이나 프록시가 요청을 마치는 데 필요한 응답을 제때 받지 못했다는 뜻입니다. 브라우저 앞에 로드밸런서나 CDN이 있다면, 요청 시..

게시판에 502가 뜨면 애플리케이션부터 재시작하고 싶어집니다. 그런데 앱이 8081번 포트에서 정상 동작하고 Nginx만 8080번으로 요청을 보내는 상황이라면, 재시작을 반복해도 같은 화면을 보게 됩니다. 이 글은 Nginx와 HTTP 애플리케이션이 같은 Linux 서버에서 실행되고, Nginx 오류 로그에 연결 거절이 찍힌 상황을 다룹니다.오류 로그에 찍힌 목적지Nginx에서 upstream은 요청을 넘겨받는 뒤쪽 서버를 뜻합니다. 브라우저의 502 화면을 확인했다면, 먼저 실패한 요청의 시각과 경로를 기준으로 Nginx 오류 로그를 찾습니다. 아래는 게시판 조회 요청에 대해 구성한 가상 로그입니다.2026/11/06 10:00:10 [error] *42 connect() failed (111: Co..