KapsuleHost에서 .htaccess 이해하기

KapsuleHost는 모든 웹사이트를 .htaccess를 읽지 않는 고성능 웹 서버로 제공하므로, 해당 파일에 추가한 규칙은 아무런 효과가 없습니다. 이 가이드는 이것이 WordPress 사이트에 어떤 의미인지 설명하고, 같은 역할을 대신 수행하는 KPanel 설정을 보여줍니다.

공유 cPanel 호스트에서 옮겨 오셨다면, .htaccess는 아마도 리디렉션, HTTPS 강제 적용, 사용자 지정 오류 페이지, 봇 차단 설정을 넣어두던 곳이었을 것입니다. 이 모든 기능은 KapsuleHost에서도 그대로 작동합니다. 다만 텍스트 파일이 아니라 KPanel에서 설정하며, 서버 수준에서 적용되기 때문에 더 빠르고 오타 하나로 사이트가 망가지는 일도 없습니다.

.htaccess가 여기서 아무 효과가 없는 이유

.htaccess는 Apache 웹 서버를 위한 디렉토리별 설정 파일입니다. Apache는 모든 요청마다 이 파일을 다시 읽는데, 이것이 이 파일을 편리하게 만드는 동시에 느리게 만드는 이유이기도 합니다.

KapsuleHost는 Apache를 실행하지 않습니다. 귀하의 사이트는 시작 시 설정을 한 번만 불러오는 이벤트 기반 웹 서버에 의해 제공되며, 이것이 이곳의 사이트가 부하 상황에서 더 빠르게 응답하는 주된 이유입니다. 이 서버에는 디렉토리별 재정의 파일에 해당하는 개념이 전혀 없으므로, .htaccess를 여는 일 자체가 없습니다.

좋은 소식은 흔히 겪는 .htaccess 악몽 이야기의 정반대 상황이라는 점입니다. 이 파일을 아무도 해석하지 않으므로, 파일 안의 구문 오류가 여기서는 사이트를 다운시킬 수 없습니다.

.htaccess 없이도 계속 작동하는 것들

고유주소(Permalinks). WordPress 사이트가 Apache에서 .htaccess를 필요로 하는 가장 흔한 이유는 보기 좋은 고유주소 기능입니다. KapsuleHost에서는 재작성(rewrite) 기능이 사이트의 서버 설정에 내장되어 있으므로, /2026/07/my-post/는 .htaccess 블록이 전혀 없어도 WordPress를 통해 정상적으로 해석됩니다. 고유주소에서 404 오류가 발생한다면 원인은 다른 곳에 있습니다. WordPress 고유주소 문제 해결하기를 참고하세요.

WordPress가 파일에 쓰는 내용. WordPress와 일부 플러그인은 여전히 Apache를 전제로 하여 # BEGIN/# END 블록을 .htaccess에 기록합니다. 이는 무해합니다. 파일은 실제로 존재하고 쓰기도 가능하며, 파일 관리자에서도 보입니다. 다만 그것을 읽는 쪽이 없을 뿐입니다.

"보안 강화가 적용되었습니다"라고 알리는 보안 플러그인. xmlrpc.php나 wp-config.php를 .htaccess 수정을 통해 잠갔다고 주장하는 플러그인은 이 플랫폼에서는 실제로 아무것도 보호하지 못한 것입니다. 사이트 자체의 보안 탭을 사용하세요. 이 탭은 동일한 규칙을 서버 수준에서 적용합니다.

자주 쓰이는 .htaccess 규칙에 대응하는 KPanel 설정

다음은 모두 사이트 자체 안에 있습니다. 웹사이트, 그다음 해당 사이트, 그다음 표에 나온 탭 순서입니다.

이 중 두 가지는 .htaccess 방식으로는 결코 할 수 없었던 일까지 해냅니다. 리디렉션은 정확한 경로, 후행 슬래시 접두사, /blog/* 같은 와일드카드를 지원하며, KPanel은 저장 후 실시간으로 리디렉션을 검증합니다. 오류 페이지는 실제 상태 코드와 함께 제공되므로, 사용자 지정 404 페이지도 검색 엔진에게는 사과문이 붙은 200이 아니라 진짜 404로 인식됩니다.

파일 찾고 읽어보기

여전히 .htaccess를 들여다보고 싶을 수 있습니다. 보통은 어떤 플러그인이 그 안에 무엇을 써 넣었는지 확인하거나, KPanel에서 다시 만들기 전에 규칙을 복사해 두기 위해서입니다.

WordPress 탭에서 확인하기

1. KPanel에 로그인한 뒤 왼쪽 사이드바에서 웹사이트를 클릭합니다.
2. 원하는 사이트를 클릭합니다.
3. WordPress 탭을 연 다음 wp-config 섹션을 엽니다.
4. .htaccess 패널까지 스크롤합니다. 내용은 읽기 전용으로 표시되며, 변경이 필요하면 Edit 버튼을 사용할 수 있습니다.

파일 관리자에서 확인하기

1. 사이트를 연 다음 설정, 그다음 파일 관리자를 엽니다.
2. 도구 모음에서 숨김 파일 표시을 클릭합니다. 점(.)으로 시작하는 파일은 기본적으로 숨겨져 있으므로, 이 작업을 하기 전까지는 .htaccess가 보이지 않습니다.
3. .htaccess를 클릭하면 내장 편집기에서 열립니다.

이 파일은 사이트의 루트에 위치하며, wp-config.php 및 wp-content과 함께 있습니다. 편집기와 그 권한 제어 기능에 대한 자세한 내용은 파일 관리자 사용하기에서 확인하실 수 있습니다.

기본 WordPress 블록

참고로, 이것은 WordPress가 스스로를 위해 작성하는 블록입니다. Apache 호스트에서는 고유주소를 구동하지만, KapsuleHost에서는 비활성 상태이며 삭제해도 아무것도 깨지지 않습니다.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

나중에 Apache 호스트로 사이트를 옮길 가능성이 있다면 그대로 두세요. 어차피 고유주소 설정을 다시 저장하는 순간 WordPress가 다시 작성합니다.

규칙을 옮겨오는 경우

cPanel에서 사이트를 옮겨올 때는, 기존 호스팅을 해지하기 전에 기존 .htaccess 파일을 열어 한 줄씩 확인하며 작업하세요.

1. 리디렉션. 각 Redirect 또는 RewriteRule 규칙을 설정, 그다음 리다이렉트에서 다시 만듭니다. 규칙 하나당 행 하나입니다. 영구적인 변경이라면 301을, 되돌릴 가능성이 있다면 302를 선택하세요.
2. HTTPS 강제 적용. 해당 규칙은 삭제하세요. 대신 사이트의 설정에서 HTTPS 강제 적용를 켜세요.
3. IP 차단. WordPress, 그다음 보안의 IP 차단 패널에서 다시 만드세요.
4. 캐싱 및 압축 헤더. 삭제하세요. 이는 자동으로 처리되며, 이전 호스트에서 넘어온 오래된 mod_expires 규칙은 혼란스러운 캐시 동작의 흔한 원인이 됩니다.
5. 플러그인이 작성한 모든 내용. 무시하세요. 새 사이트에 플러그인을 다시 설치하여 자체적으로 처리하게 두세요.

마이그레이션 과정에서도 파일 자체는 그대로 유지되므로, 목록을 처리하는 동안 아무것도 손실되지 않습니다. 전체 마이그레이션 안내는 cPanel에서 웹사이트 마이그레이션하기를 참고하세요.

문제 해결

"리디렉션을 .htaccess에 추가했는데 아무 일도 일어나지 않았어요." 예상된 결과입니다. 설정, 그다음 리다이렉트에서 추가하세요. 그곳의 Status 열에서 리디렉션이 실시간으로 검증되었는지 확인할 수 있습니다.

"플러그인은 사이트가 보안 강화되었다고 하는데 스캐너는 다르게 말합니다." 해당 플러그인은 읽히지 않는 .htaccess 규칙을 작성한 것입니다. 실제로 적용된 보호 기능은 사이트의 보안 탭에서 확인하세요.

"이전 호스트의 .htaccess에 이해할 수 없는 규칙이 있어요." 무작정 복사해 넣지 마세요. 해당 파일을 첨부하여 티켓을 열어 주시면, 어떤 규칙이 KapsuleHost에서 대응되는 기능을 가지고 있는지, 어떤 것이 단지 공유 Apache 호스트를 보완하기 위한 것이었는지 안내해 드리겠습니다.

"고유주소가 깨졌어요." 이는 여기서 .htaccess 문제가 아닙니다. WordPress 고유주소 문제 해결하기로 이동하거나, 사이트의 WordPress 탭에서 빠른 작업, 그다음 Rewrites 비우기를 선택하여 재작성 규칙을 비워주세요.