검색어 C++가 공백으로 바뀐 이유: +·%2B·빈값 URL 인코딩 실험
Python 표준 라이브러리로 여섯 검색어를 직접 연결한 쿼리와 urlencode 결과를 대조했습니다. +·&·=·빈값·중복 키를 구분하고 원본 입력이 돌아오는지 검증하는 코드를 공개합니다.
PUNCHBLOG / ALL RECORDS
운영 기록 찾아보기
실제 운영 사례 3편과 격리 실험 19편. 제목·설명·주제로 원하는 기록을 찾으세요.
전체 22편
서비스를 옮긴 뒤 예전 주소는 왜 열릴까: 410·이동·noindex를 나눈 기록
네 서비스의 화면 이전 뒤 설치 앱의 데이터 주소까지 410이 된 문제를 확인했습니다. 화면 종료와 데이터 호환 경로를 나눈 복구 및 공개 GET 12건을 기록합니다.
AAAA 주소에서 숫자 하나가 빠졌다: 펀치블로그의 IPv6 수정 기록
실제 DNS 변경 전후 기록에서 406과 2406의 차이를 확인했다. 주소 형식 검사만으로 놓치는 문제, IPv4·IPv6를 따로 검사한 결과와 수정 범위를 검증한 방법을 정리한다.
헬스체크 200은 무엇을 확인할까: 작업 대역으로 준비 조건 나누기
Python HTTP 서버·대기 스레드·의존성 변수를 사용한 격리 실험입니다. 응답 가능 여부와 준비 상태를 나누며 실제 작업 완료를 시험한 것과 구분합니다.
curl -I의 200만으로 충분할까: HEAD·GET 배포 확인 실험
같은 네 경로에 HEAD와 GET을 보내 상태·본문·릴리스 문자열을 비교했다. 200 응답만으로 배포 완료를 판단할 수 없는 경우를 격리 실험으로 확인한다.
SQLite database is locked: WAL만 켜지 말고 busy_timeout 확인하기
WAL 모드에서도 writer는 하나뿐이었다. timeout 0초·0.2초·1.5초를 비교해 즉시 실패, 대기 후 실패, 잠금 해제 뒤 성공을 실제로 측정한다.
예약 작업을 멈췄는데 다시 실행된다면: stop과 disable을 나눠 확인하기
서비스를 stop해도 타이머가 다시 실행했고, disable된 타이머도 active 상태로 남았다. 실제 systemd 사용자 유닛 실험으로 중지·등록 해제·완료 조건의 차이를 확인한다.
터미널에서는 되는데 예약 작업에서는 실패한다면: 경로와 환경부터 비교하기
같은 Python 스크립트도 실행 위치와 환경변수가 달라지면 실패했다. 여덟 가지 격리 실험으로 상대 경로, 필수 설정, PATH 문제를 구분하고 예약 작업에서 확인할 조건을 정리한다.
로그를 지웠는데 디스크가 그대로라면: 열린 파일부터 확인하기
8 MiB 임시 로그를 지운 뒤에도 할당 공간이 남고 추가 기록이 가능했다. 같은 이름의 새 파일과 기존 파일 디스크립터를 비교해, 삭제 뒤 용량이 줄지 않는 원인을 좁힌다.
HTTPS 원본을 IP로 검사하면 왜 실패할까: Host와 --resolve 비교
같은 루프백 서버에 네 가지 방식으로 접속했다. SNI, 인증서 이름, CA 신뢰를 구분하고 검증을 유지한 원본 확인 방법을 살핀다.
gzip을 켰는데 압축이 안 된다면: 요청 헤더와 실제 바이트 확인
같은 합성 문장을 identity와 gzip으로 요청했다. 6,160바이트가 317바이트로 전송된 조건과 짧은 파일이 압축되지 않은 조건을 구분한다.
갱신 순간에만 JSON 오류가 난다면: 검증한 파일로 교체하기
파일을 절반만 쓴 순간을 고정해 읽었다. 직접 덮어쓰기의 JSON 오류와 임시 파일 검증 후 교체의 결과를 비교한다.
시간 초과 뒤 재시도했더니 두 번 저장됐다: 요청과 결과를 구분하기
응답을 받지 못해도 서버에는 메모가 남아 있었다. 단순 재시도와 같은 요청 키로 기존 결과를 돌려주는 처리를 비교했다.
nginx -t는 통과했는데 응답 헤더가 사라졌다: 상속과 always
location에 헤더 하나를 추가하자 상위 헤더가 빠졌다. 정상 응답과 404를 나눠 확인하고, 문법 검사가 놓치는 설정 동작을 살핀다.
예약 작업이 겹칠 때: 파일 존재 검사와 flock의 차이
첫 작업이 끝나기 전에 두 번째 작업을 시작했다. 잠금 유무, 건너뛰기, 비정상 종료 후 다음 실행을 임시 프로세스로 확인한다.
SQLite 백업이 정상이라는데 최신 글이 없다면: 복구로 확인하기
무결성 검사는 통과했지만 16개 중 12개만 남은 복사본을 만들었다. WAL 상태, backup API, 별도 경로 복구를 비교한다.
도메인을 등록했는데 사이트가 안 열렸다: 펀치블로그 연결 기록
Lightsail에 도메인이 보여도 실제 DNS는 Cloudflare가 담당했다. DNS, 서버의 도메인 설정, HTTPS 인증서를 나눠 확인하고 연결한 과정과 공개 응답을 기록한다.
파일을 덮어쓰지 않고 정적 사이트의 배포 위치 바꾸기
두 완성된 디렉터리 사이에서 current 링크를 교체했다. 재시작 없이 바뀐 응답과, 이것만으로 해결되지 않는 배포 문제.
Nginx 설정 검사부터 반영 확인까지: nginx -t 성공 뒤에도 볼 것
잘못된 후보는 검사에서 걸렸지만, 올바른 후보도 검사만으로는 실행 중인 응답을 바꾸지 못했다. 후보 파일, 반영 대상, 실제 응답을 차례로 확인하는 절차를 정리한다.
304 응답의 본문이 0바이트인 이유를 직접 확인했다
첫 요청의 ETag를 다음 요청에 돌려보냈다. 같은 파일이 200에서 304로 바뀌었을 때 무엇을 다시 쓰는지 정리한다.
원본이 503이어도 화면은 200: 오래된 캐시를 구분하는 법
MISS → HIT → STALE을 순서대로 재현했다. 장애 중 저장본을 내보내는 설정과 모니터링의 사각지대를 함께 살핀다.
없는 글과 CSS가 200으로 열린다: Nginx try_files 진단 순서
없는 글뿐 아니라 없는 CSS도 홈 HTML과 200으로 돌아올 수 있었다. 정상 글·없는 글·없는 자산을 비교해 정적 사이트의 잘못된 fallback을 찾는다.
일치하는 기록이 없습니다. 검색어를 줄이거나 주제·기록 유형을 ‘모든 기록’으로 바꿔보세요.
여러 기록을 연결해서 읽으려면
GUIDE 01 / 연결 진단
사이트가 안 열릴 때: DNS부터 HTTPS까지 좁혀가기
DNS를 바꿀지, 웹 서버를 볼지 결정하기 전에 요청이 어디까지 도착했는지 확인합니다. IPv4·IPv6와 원본 서버를 나눠 검사하는 순서입니다.
6단계 · 5편의 근거 기록가이드 읽기 →
GUIDE 02 / 배포와 되돌리기
정적 사이트 배포: 새 파일 확인부터 되돌리기까지
홈이 열리는 것만으로 배포를 끝내지 않습니다. 후보 폴더, 웹 서버의 읽기 권한, 이전 CSS, 없는 주소, 롤백까지 한 흐름으로 확인합니다.
6단계 · 5편의 근거 기록가이드 읽기 →
GUIDE 03 / 백업과 복구
SQLite 백업: 파일이 아니라 복구한 내용으로 확인하기
무결성 검사가 정상이더라도 최신 데이터는 빠질 수 있습니다. WAL 모드의 백업을 별도 경로에서 복원하고, 필요한 내용까지 대조하는 절차입니다.
6단계 · 4편의 근거 기록가이드 읽기 →