콘텐츠로 건너뛰기
DevLab

🟩 nginx.conf 생성기

호스트 · 루트 디렉토리 · SSL 인증서 경로를 입력하고 체크박스로 기능 선택. HTTPS 리디렉션 · HTTP/2 · 모던 TLS · HSTS · gzip · 정적 캐시 · PHP-FPM · 리버스 프록시 · WebSocket · try_files 까지 실전 server 블록을 실시간 생성.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

🔒 개인정보 보호

🎛 프리셋

🧩 기능 선택

📄 생성된 nginx.conf


        
    






    
📖 자주 걸리는 지점


        
정적 사이트·리버스 프록시·PHP-FPM 같은 구성으로부터 server 블록을 포함한 nginx.conf 를 생성합니다. SSL·gzip·캐시·보안 헤더의 지정도 함께 출력할 수 있습니다. 처리는 브라우저 안에서 끝납니다. 다만 생성할 수 있는 것은 구문이지 당신의 환경에서 올바르게 동작한다는 보증이 아닙니다 — 인증서의 경로가 존재하는지, upstream 에 도달할 수 있는지, 도큐먼트 루트가 맞는지는 검증할 수 없습니다. 그리고 nginx 에서 시간을 잃는 것은 대개 설정을 「잘못 쓴」 때가 아니라 「쓴 셈인 의미와 nginx 가 해석한 의미가 달랐던」 때입니다.

    
        

        

            
                

                    사례
                    무슨 일이 일어나는가
                    어떻게 하면 되는가
                

            
            
                                

                    location 은 쓴 순서대로 평가되지 않는다
                    nginx 는 location 을 위에서부터 순서대로 시도하는 것이 아니라 정해진 우선순위로 고릅니다. 먼저 = 의 완전 일치, 다음으로 최장의 전방 일치 (^~ 가 붙어 있으면 거기서 확정), 그 후에 정규식 (~ / ~*) 을 기술 순서대로, 어느 것도 일치하지 않으면 먼저 보류한 최장의 전방 일치가 쓰입니다. 즉 블록을 위아래로 옮겨도 아무것도 변하지 않는 경우가 많고, 반대로 정규식 블록을 하나 더하면 전방 일치 블록이 처리하던 요청을 조용히 빼앗습니다. 전형적인 증상은 정적 파일이 PHP 로 넘어가 버리는 (또는 그 반대) 것이며 location ~ \.php$ 와 location /assets/ 의 관계를 오해하고 있을 때 일어납니다.
                    추측하지 말고 nginx -T 를 실행하세요. include 를 모두 전개한 최종 설정이 표시되므로 「어딘가 다른 파일에도 같은 location 이 있다」 같은 놓침이 그 자리에서 드러납니다. 설계로는 정적 파일을 먼저 확정시키는 것이 안전합니다 — location ^~ /assets/ 라고 쓰면 거기서 정규식 평가가 멈춥니다. 첫 페이지나 favicon.ico 처럼 하나로 정해지는 URL 은 = 로 쓰면 가장 빠르고 의도도 명확해집니다. 변경 후에는 반드시 구체적인 URL 을 curl 로 두드려 확인하세요 — 설정을 읽고 옳아 보이는 것과 실제로 어느 블록이 선택되는가는 별개입니다.
                

                                

                    add_header 는 상속이 아니라 덮어쓰기된다
                    nginx 의 상속에는 직관에 반하는 규칙이 있습니다. 자식 블록이 같은 디렉티브를 하나라도 쓰면 부모에서 쓴 같은 종류의 디렉티브는 전부 무효가 됩니다 — 「더해지는」 것이 아니라 「치환되는」 것입니다. 실해가 큰 것이 add_header 로, server 블록에 보안 헤더를 다섯 개 써 두고 location ~ \.php$ 안에 캐시 제어를 한 줄 더한 것만으로 PHP 응답에서 보안 헤더가 다섯 개 모두 사라집니다. 오류도 경고도 나오지 않습니다 — 진단 사이트에서 「헤더가 없다」는 말을 듣고서야 알아채는 종류입니다. 같은 규칙은 proxy_set_header 에도 적용됩니다 — location 안에서 하나 더하면 상위에서 설정한 프록시 헤더가 전부 사라집니다.
                    먼저 curl -I 로 실제 응답 헤더를 확인하세요 — 설정에 적혀 있는 것과 돌아오는 것은 별개입니다. 대처는 둘입니다. 헤더를 한 곳에 모으고 하위 블록에서는 add_header 를 일절 쓰지 않는 것이 가장 단순합니다. 그것이 무리라면 헤더 묶음을 별도 파일로 떼어 내 필요한 location 마다 include 합니다 — 중복되지만 사라지는 것보다 훨씬 낫습니다. 그리고 add_header 에는 always 를 붙이세요 — 붙이지 않으면 4xx 나 5xx 응답에는 헤더가 붙지 않습니다 (오류 페이지야말로 지키고 싶은 장면이 많은데 말입니다). 같은 주의는 proxy_set_header 에도 해당됩니다.
                

                                

                    리버스 프록시에서 깨지는 것은 헤더와 크기
                    proxy_pass 를 쓴 것만으로는 애플리케이션은 자신이 어느 호스트명으로 어느 프로토콜로 불렸는지를 모릅니다. Host 와 X-Forwarded-Proto 를 넘기지 않으면 애플리케이션은 http://localhost:3000/... 같은 URL 을 생성하고 리다이렉트가 루프하고 쿠키의 도메인이 어긋납니다. proxy_pass 의 끝 슬래시도 의미가 달라집니다 — proxy_pass http://app; 은 원래 경로를 그대로 넘기고 proxy_pass http://app/; 은 location 부분을 떼어 내고 넘깁니다. 이 한 글자로 404 가 됩니다. 크기와 시간의 기본값도 주의가 필요해서 client_max_body_size 의 기본값은 1MB — 그것을 넘는 업로드는 애플리케이션에 닿기 전에 413 으로 튕깁니다. WebSocket 은 Upgrade 와 Connection 을 명시하지 않으면 접속할 수 없습니다.
                    프록시의 location 에는 최소한 이 넷을 쓰세요: proxy_set_header Host $host;, X-Real-IP $remote_addr;, X-Forwarded-For $proxy_add_x_forwarded_for;, X-Forwarded-Proto $scheme;. 그리고 애플리케이션 쪽에서 그것들을 신뢰하는 설정 (trusted proxies) 을 활성화하세요 — 한쪽만으로는 듣지 않습니다. 업로드를 다룬다면 client_max_body_size 를 애플리케이션 쪽 상한과 맞추고, 시간이 걸리는 처리가 있다면 proxy_read_timeout (기본 60 초) 도 함께 늘립니다 — 어느 한쪽만 바꿔도 짧은 쪽에서 끊깁니다. 반영은 nginx -t && nginx -s reload 로 하고, 502 가 나올 때는 access.log 가 아니라 error.log 를 보세요 — 원인은 거의 반드시 그쪽에 적혀 있습니다.
                

                            
        

    

    
        
편집한 것만으로는 아무것도 변하지 않습니다. nginx 는 기동할 때 설정을 읽어 들인 채이므로 파일을 저장해도 reload 할 때까지 거동은 바뀌지 않습니다 — 「고쳤는데 낫지 않는다」고 생각했다면 먼저 리로드했는지를 확인하세요. 순서는 반드시 nginx -t 로 구문을 검사한 뒤 reload 입니다 — 검사하지 않고 restart 하면 설정에 오류가 있었을 때 nginx 가 기동하지 않아 사이트가 완전히 멈춥니다 (reload 라면 설정이 부정해도 예전 설정으로 계속 동작합니다). 인증서에 대해 하나: ssl_certificate 에는 cert.pem 이 아니라 fullchain.pem 을 지정하세요 — 중간 인증서가 빠져 있으면 브라우저에서는 정상으로 보이는데 curl·모바일 앱·오래된 환경에서는 검증에 실패합니다. 이 결함은 「내 환경에서는 재현되지 않기」 때문에 보고될 때까지 알아챌 수 없습니다. 마지막으로 설정 파일은 반드시 버전 관리하세요 — 프로덕션 서버 위에서 직접 편집한 변경은 다음 배포에서 조용히 사라집니다.

    









    
📖 사용법

    
    
                
  1. 
            1
            
    
                
    프리셋 선택
    
                
    정적 / WordPress / Laravel / Next.js 선택 시 권장 기능이 자동 체크.
    
            
    
        
    2. 
                
  2. 
            2
            
    
                
    호스트와 SSL 경로 입력
    
                
    server_name, 루트, Lets Encrypt 인증서 경로 입력.
    
            
    
        
    3. 
                
  3. 
            3
            
    
                
    복사 또는 다운로드
    
                
    오른쪽 상단 버튼으로 복사 또는 .conf 다운로드.
    
            
    
        
    4. 
                
  4. 
            4
            
    
                
    nginx 에 배치 후 재시작
    
                
    /etc/nginx/sites-available/ 에 배치 후 sites-enabled 심볼릭 링크 → nginx -t → systemctl reload nginx.
    
            
    
        
    5. 
            






    
❓ 자주 묻는 질문

    

                

            
                SSL 인증서가 없으면 어떻게 합니까?
                
            
            
Lets Encrypt certbot 으로 무료 발급. HSTS 는 HTTPS 가 완전히 작동한 후에 활성화.

        

                

            
                nginx -t 에서 에러가 발생합니다
                
            
            
대부분 SSL 경로 오타 또는 PHP-FPM 소켓 경로 불일치. 오류 행 번호와 journalctl 확인.

        

                

            
                nginx 에서 Apache .htaccess 사용 가능?
                
            
            
불가. nginx 는 .htaccess 를 읽지 않습니다. Apache 호스트는 별도의 .htaccess 생성기 사용.

        

            






    

        
🔗 관련 도구

        
    






    

        
            🐛 이 도구에서 문제가 발생했나요?
            
        

        

            무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
        


        

                        

            

                
                
            


            

                
                
                

                    ※ 재현을 위해 브라우저 정보 (UA / 화면 / 언어 / URL) 가 자동 전송됩니다