콘텐츠로 건너뛰기
DevLab

⚙️ .htaccess 생성기

체크박스만으로 HTTPS 리디렉션 · HSTS · gzip · 캐시 · 시크릿 파일 차단 · WordPress 퍼머링크 등 실전 .htaccess 를 실시간 생성.

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

🔒 개인정보 보호

🧩 기능 선택

📄 생성된 .htaccess


        
    






    
📖 자주 걸리는 지점


        
HTTPS 로의 리다이렉트, www 통일, PHP 버전 지정, 캐시 제어, 보안 헤더, 접근 제한 등을 조합해 .htaccess 를 생성합니다. 처리는 브라우저 안에서 끝납니다. .htaccess 에는 다른 설정 파일에는 없는 위험한 성질이 있습니다 — 한 줄의 오류로 그 디렉터리 이하 전부가 즉시 500 오류가 됩니다. 게다가 오류 화면은 원인을 알려 주지 않습니다. 관리 화면도 같은 범위에 들어 있다면 거기서는 고칠 수 없습니다 — 편집하기 전에 되돌릴 수단이 있는지 확인하세요.

    
        

        

            
                

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

            
            
                                

                    한 줄의 오류로 사이트 전체가 500 이 된다
                    .htaccess 는 요청할 때마다 다시 읽히므로 오류는 저장한 순간부터 모든 요청에 영향을 미칩니다. 가장 흔한 원인은 로드되지 않은 모듈용 디렉티브입니다 — mod_headers 가 비활성인 환경에서 Header set ... 라고 쓰면 Apache 는 그 줄을 이해하지 못하고 500 Internal Server Error 를 돌려줍니다. 「문법은 옳은데 동작하지 않는다」가 아니라 「설정을 읽을 수 없으니 전부 멈춘다」는 점이 까다롭습니다. 그리고 표시되는 것은 범용 오류 페이지뿐이고 몇 번째 줄의 무엇이 문제인지는 적혀 있지 않습니다 — 그 정보는 서버의 오류 로그에만 있습니다. 공유 호스팅에서 로그를 볼 수 없는 환경이라면 원인 특정이 전수 조사가 됩니다.
                    모듈 의존 디렉티브는 반드시 <IfModule> 로 감싸세요. <IfModule mod_headers.c> 안에 쓰면 모듈이 없는 환경에서는 그냥 무시될 뿐 500 이 되지 않습니다 — 이것만으로 사고의 대부분을 막을 수 있습니다. 작업 절차로는 편집 전에 반드시 사본을 뜨고 SSH 나 FTP 처럼 「사이트가 500 이어도 쓸 수 있는 경로」에서 편집하세요 — WordPress 관리 화면에서 편집하는 것은 자기 발판을 부수는 작업입니다. 그리고 조금씩 더하고 그때마다 브라우저로 확인하세요 — 열 줄을 한꺼번에 추가한 뒤 500 이 되면 어느 것이 원인인지 이분 탐색을 하게 됩니다. 공유 호스팅이라면 먼저 오류 로그를 볼 수 있는지를 미리 확인해 두면 정작 필요할 때 곤란하지 않습니다.
                

                                

                    리다이렉트가 루프한다 / 301 을 지울 수 없다
                    HTTPS 강제와 www 통일을 동시에 쓰면 조건의 순서에 따라 무한 루프가 됩니다. 특히 로드밸런서나 CDN 이 앞단에 있는 구성에서는 서버에는 늘 HTTP 로 도착하므로 %{HTTPS} 가 언제까지나 off 인 채여서 리다이렉트가 영원히 반복됩니다 — 증상은 ERR_TOO_MANY_REDIRECTS 입니다. 그리고 여기에 301 의 성질이 겹칩니다: 301 은 「항구적」이라 브라우저가 강하게 캐시하고 설정을 고친 뒤에도 브라우저는 예전 리다이렉트를 계속 실행합니다. 결과적으로 「고쳤는데 낫지 않는」 상태가 되어 더 설정을 만지작거리며 사태를 악화시킵니다 — 이런 종류의 문제에서 가장 시간을 잃는 패턴입니다.
                    프록시 뒤에 있다면 %{HTTP:X-Forwarded-Proto} 를 보세요. RewriteCond %{HTTP:X-Forwarded-Proto} !https 라고 쓰면 CDN 을 거쳐도 올바르게 판정할 수 있습니다. 그리고 검증은 반드시 브라우저가 아니라 curl -I 로 하세요 — curl 은 리다이렉트를 캐시하지 않으므로 언제나 현재 설정의 결과를 볼 수 있습니다. 만드는 도중에는 302 를 쓰고 의도대로 동작하는 것을 확인한 뒤에 301 로 바꾼다 — 이 순서만으로 캐시에 기인한 사고는 거의 전부 피할 수 있습니다. 이미 잘못된 301 을 배포해 버렸다면 올바른 곳으로 다시 301 을 돌려주는 것이 유일한 대처입니다 — 브라우저의 캐시는 당신 쪽에서 지울 수 없습니다. 그리고 리다이렉트 규칙은 한 곳에 모으세요 — 여러 .htaccess 나 애플리케이션 쪽 설정에 흩어져 있으면 루프의 원인을 추적할 수 없게 됩니다.
                

                                

                    서브디렉터리의 .htaccess 가 부모의 규칙을 지운다
                    .htaccess 는 계층적으로 적용되지만 mod_rewrite 의 규칙만은 「상속」이 아니라 「치환」입니다. 서브디렉터리에 RewriteRule 을 하나라도 쓰는 순간 부모 디렉터리의 재작성 규칙은 그 디렉터리에서는 무효가 됩니다 — HTTPS 강제도 www 통일도 거기서만 듣지 않게 됩니다. 알아채기 어려운 것은 다른 디렉티브 (인증·캐시·헤더) 는 평범하게 상속되기 때문이며 「일부만 상속된다」는 직관에 반하는 거동이 됩니다. 관련해서 서브디렉터리에서는 RewriteBase 의 지정이 필요한 경우가 있고 이것을 쓰는 것을 잊으면 상대 경로가 부모의 경로로 해석되어 404 나 루프를 일으킵니다.
                    가능하면 .htaccess 를 쓰지 말고 서버 본체의 설정에 쓰세요. VPS 나 전용 서버라면 <Directory> 블록에 쓸 수 있습니다 — 요청할 때마다 파일을 찾아 읽는 처리가 없어지므로 속도에서도 유리합니다 (AllowOverride None 으로 하면 Apache 는 찾으러 가지조차 않습니다). 공유 호스팅에서 .htaccess 밖에 쓸 수 없다면 재작성 규칙을 부모 한 곳에 집약하고 서브디렉터리에는 RewriteRule 을 두지 않도록 하세요. 정말로 필요하다면 RewriteOptions Inherit 를 쓰면 부모의 규칙을 이어받을 수 있습니다만 적용 순서가 바뀌므로 그 경우에는 반드시 모든 패턴을 실제로 두드려 확인하세요.
                

                            
        

    

    
        
보안 헤더는 붙이면 안전해지는 것이 아닙니다. X-Frame-Options 나 Content-Security-Policy 는 특정 공격 기법을 봉쇄할 뿐이며 애플리케이션 쪽 취약점에는 아무 효과가 없습니다 — 진단 도구의 점수가 오르는 것과 실제로 안전해지는 것은 별개입니다. 특히 Content-Security-Policy 는 붙이는 방법을 틀리면 자기 사이트의 JavaScript 가 동작하지 않게 됩니다 — 먼저 Content-Security-Policy-Report-Only 로 상황을 본 뒤에 실제 지정으로 바꾸세요. 또 하나, .htaccess 에서의 접근 제한은 「그 파일이 Apache 를 거쳐 배포될 때」에만 듣습니다 — nginx 가 앞단에서 정적 파일을 직접 돌려주는 구성에서는 .htaccess 는 애초에 읽히지 않습니다. 기밀 파일은 공개 디렉터리 밖에 두는 것이 정석이고 접근 제한으로 숨기는 것은 차선책입니다. 그리고 잊기 쉽지만 .htaccess 자체도 버전 관리하세요 — 언제 누가 무엇을 더했는지 알 수 없는 설정 파일은 언젠가 아무도 건드리지 못하게 됩니다.

    









    
📖 사용법

    
    
                
  1. 
            1
            
    
                
    기능 선택
    
                
    왼쪽 체크박스에서 원하는 기능 선택. 오른쪽에 실시간 미리보기.
    
            
    
        
    2. 
                
  2. 
            2
            
    
                
    도메인 입력
    
                
    www 정규화 시 도메인 (예: example.com) 입력. HTTPS 리디렉션만이면 불필요.
    
            
    
        
    3. 
                
  3. 
            3
            
    
                
    복사 또는 다운로드
    
                
    오른쪽 상단 버튼으로 복사 또는 파일 다운로드. 업로드 전에 확인.
    
            
    
        
    4. 
                
  4. 
            4
            
    
                
    서버에 배치
    
                
    문서 루트 (public_html / htdocs / public) 에 .htaccess 로 배치. 기존 파일은 백업.
    
            
    
        
    5. 
            






    
❓ 자주 묻는 질문

    

                

            
                Apache 이외에서도 사용 가능합니까?
                
            
            
아니요. Apache 전용. LiteSpeed 는 호환되지만 nginx 는 server 블록이 필요합니다.

        

                

            
                500 에러가 발생하면?
                
            
            
미지원 모듈이 원인일 수 있습니다. IfModule 로 감싸져 있어 일반적으로 안전하지만, 발생 시 한 블록씩 주석 처리하며 확인. Apache error_log 도 점검.

        

                

            
                공유 호스팅 (Xserver / Sakura) 에서도 가능합니까?
                
            
            
대부분의 공유 호스팅은 .htaccess 와 AddHandler 를 허용합니다. mod_deflate / mod_expires 가 비활성인 경우 패널에서 활성화 필요.

        

            






    

        
🔗 관련 도구

        
    






    

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

        

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


        

                        

            

                
                
            


            

                
                
                

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