ls -al /var/log/nginx

2026-08-24T09:37:48.800Z

0

먼저 첨부해주신 ip addr 결과를 보면 네트워크는 정상입니다. eth1 이 172.18.1.91, eth2 가 10.18.1.91 로 둘 다 UP 이라 설정에는 문제가 없습니다.

접속이 안 되는 원인은 지난번에 만드신 더미 파일일 가능성이 높습니다. 루트 파티션이 꽉 찬 상태에서는 웹 서버가 정상적으로 응답하지 못합니다. 제가 지난 답변에서 실습 끝나면 반드시 지워달라고 말씀드린 이유가 바로 이것입니다.

cent1 에서 아래 순서대로 확인하고 정리해주세요.

df -h
rm -f /var/log/nginx/testfile_delete_me
df -h

두 번째 df -h 에서 사용률이 원래대로 돌아왔는지 확인하신 다음, 브라우저에서 다시 접속해보세요. 여기서 해결되면 그대로 다음 실습으로 넘어가시면 됩니다.

만약 디스크를 정리했는데도 접속이 안 되면, 그때는 서버 자체가 문제인지 윈도우에서 서버까지 가는 구간이 문제인지 쪼개야 합니다. 브라우저는 이 둘을 구분해주지 못하니까요. cent1 에서 아래 한 줄이면 갈립니다.

curl -I http://localhost/www/index.html

결과별로 이렇게 판단하시면 됩니다.

HTTP/1.1 200 OK 가 나온 경우

서버는 정상이니 윈도우 명령 프롬프트에서 ping 172.18.1.91 을 쳐보세요. 응답이 없으면 호스트 전용 어댑터 문제이니 가상머신 설정에서 어댑터 2와 3이 순서대로 연결되어 있는지 확인하시면 됩니다. 응답이 오는데도 브라우저만 안 되면 같은 창에서 curl -I http://172.18.1.91/www/index.html 로 한 번 더 확인해보세요.

Connection refused 가 나온 경우

nginx 가 떠 있지 않습니다. systemctl status nginx 로 상태를 보고 systemctl restart nginx 로 다시 올리세요.

404 Not Found 가 나온 경우

nginx 는 정상인데 파일이 그 경로에 없는 것입니다. ls -al /usr/share/nginx/html/www/index.html 로 확인해보시고, 파일이 없으면 알려주세요.

위에 없는 결과가 나온 경우

그 한 줄만 그대로 붙여서 알려주시면 짚어드리겠습니다.

그리고 다음에 하시려는 모니터링 실습에 대해 미리 알려드릴 것이 하나 있습니다. 강의에서 감시하는 로그는 VWS.access.log 인데, 이 파일은 가상호스트 이름으로 접속했을 때만 기록됩니다. IP 로 접속하면 nginx 의 기본 서버가 응답하고 기록은 access.log 쪽으로 갑니다. 그래서 IP 로 아무리 새로고침해도 VWS.access.log 는 0 바이트인 채로 보입니다.

http://172.18.1.91/www/index.html 로 접속하면 기본 서버가 응답하고 access.log 에 기록됩니다.

http://vws.tmpcompany.com/index.html 로 접속하면 가상호스트가 응답하고 VWS.access.log 에 기록됩니다.

두 번째 방식으로 하시려면 윈도우의 C:\Windows\System32\drivers\etc\hosts 파일을 메모장 관리자 권한으로 열어 아래 한 줄을 추가하시면 됩니다.

172.18.1.91 vws.tmpcompany.com

이때 주소에서 /www/ 는 빼야 합니다. 가상호스트 쪽은 문서 루트가 이미 www 디렉터리를 가리키고 있어서, /www/ 를 붙이면 www 안의 www 를 찾다가 404 가 납니다.

hosts 파일 수정이 번거로우시면 감시 대상을 넓혀서 하셔도 학습 내용은 같습니다.

watch -n 3 'ls -al /var/log/nginx'

이렇게 디렉터리 전체를 보시면 새로고침할 때 어느 로그가 늘어나는지 눈으로 확인하실 수 있고, 오히려 기본 서버와 가상호스트의 차이를 이해하시는 데 도움이 됩니다.

감사합니다.

2026-08-24T08:00:33.576Z

0

답변감사합니다 선생님 그럼 선생님 말씀은 지금 제 서버는 아직 아무것도 한게 없기에 클린한게 정상이며 잘 못 된게 없고? 선생님은 일부로 용량 꽉차게 만들었으며,

이럴때 어떤 명령어를 사용하라 정도로만 학습을 하면 될까요?

만약 제가 좀 용량을 채우고 싶으면
dd if=/dev/zero of=tesfile_delete_me bs=1m count=5000
요걸 쓰는거구요?

0

네, 세 가지 다 맞게 이해하셨습니다.

지금 서버가 깨끗한 게 정상이고, 강의 화면의 꽉 찬 상태는 제가 촬영 전에 일부러 만들어 둔 것입니다. 잘못 따라오신 게 없습니다.

학습 포인트도 말씀하신 대로입니다. 다만 "이럴 때 이 명령어"로 외우기보다, 범위를 좁혀 들어가는 순서 자체를 손에 익히시는 걸 권합니다.

df -h 로 어느 파티션이 찼는지 → du -h --max-depth=1 로 범인 디렉터리를 한 단계씩 좁히기 → ls -alh 또는 du -sh * 로 파일 단위 확인

실무에서는 범인이 nginx 로그가 아니라 애플리케이션 로그나 오래된 백업, 코어 덤프인 경우가 훨씬 많습니다. 그때도 위 순서는 그대로 통하고, 마지막에 나오는 파일 이름만 달라집니다. 그래서 명령어보다 순서가 남는 게 중요합니다.

dd 명령은 방향은 맞는데 두 군데만 고쳐주세요.

## 잘못된 예
dd if=/dev/zero of=tesfile_delete_me bs=1m count=5000

고친 것

## 올바른 예 
cd /var/log/nginx
dd if=/dev/zero of=testfile_delete_me bs=1M count=5000

첫째, testfile 에서 t 가 하나 빠져 있습니다. 파일명이 달라지면 나중에 지우는 명령과 안 맞아서 지웠다고 생각했는데 용량이 그대로인 상황이 생깁니다.

둘째, bs 단위는 대문자 M 이어야 합니다. 소문자 m 을 쓰면 dd: invalid number: '1m' 에러가 나고 파일이 만들어지지 않습니다. GNU dd 는 K, M, G 만 1024 단위 접미사로 인식합니다.

여기서 count 값은 제 강의 화면 숫자를 그대로 쓰시면 안 되고, 본인 서버의 남은 용량에 맞춰서 정하셔야 합니다. bs=1M 이므로 count 는 그대로 MB 개수가 됩니다.

먼저 df -h 를 치고 루트 파티션 행의 Avail 열을 보세요. 그 값이 실제로 채워야 할 양입니다.

Avail 이 4.0G 면 4 x 1024 = 약 4096, 그보다 조금 크게 count=4300

Avail 이 20G 면 20 x 1024 = 약 20480, 그보다 조금 크게 count=21000

Avail 보다 작게 잡으면 100% 가 안 돼서 강의와 같은 상황이 안 만들어지고, 너무 크게 잡아도 어차피 꽉 찬 지점에서 멈추니 손해는 없습니다. 다만 Avail 이 수십 기가면 그만큼 쓰는 데 시간이 걸리니 여유를 크게 잡을 필요는 없습니다.

중간에 No space left on device 가 뜨면 실패가 아니라 의도한 상태에 도달한 것이니, 그대로 df -h 를 다시 쳐서 100% 를 확인해 보세요.

그리고 실습이 끝나면 반드시 지워주세요. 루트 파티션이 100% 인 상태로 두면 이후 실습에서 파일 쓰기가 전부 실패합니다.

rm -f /var/log/nginx/testfile_delete_me
df -h

df -h 로 사용률이 원래대로 돌아온 것까지 확인하고 다음 강의로 넘어가시면 됩니다.