KapsuleHost에서 .htaccess 이해하기

Kapsule는 .htaccess을 읽지 않는 고성능 웹 서버로 모든 웹사이트를 제공하므로, 해당 파일에 추가한 규칙은 효과가 없습니다. 이 가이드는 WordPress 사이트에서 이것이 의미하는 바를 설명하고 각 작업을 대신 수행하는 KPanel 설정을 보여줍니다.

공유 cPanel 호스트에서 이동한 경우 .htaccess은 리디렉션, HTTPS 강제 적용, 사용자 정의 오류 페이지 및 봇 차단을 설정하는 위치였을 것입니다. 이 모든 것들은 여전히 Kapsule에서 작동합니다. 텍스트 파일이 아닌 KPanel에서 설정되며, 서버 수준에서 적용되므로 더 빠르고 오타로 사이트를 손상시킬 수 없습니다.

.htaccess가 여기서 작동하지 않는 이유

.htaccess은 Apache 웹 서버를 위한 디렉터리별 구성 파일입니다. Apache는 모든 단일 요청에서 이를 다시 읽으므로 편리하지만 느립니다.

Kapsule은 Apache를 실행하지 않습니다. 사이트는 시작 시 구성을 한 번만 로드하는 이벤트 기반 웹 서버로 제공되며, 이것이 여기 사이트들이 부하 상황에서 더 빠르게 응답하는 큰 이유 중 하나입니다. 해당 서버에는 디렉터리별 재정의 파일이 동등한 기능이 없으므로 .htaccess을 절대 열지 않습니다.

좋은 소식은 일반적인 .htaccess 공포 이야기의 반대입니다. 파일의 구문 오류는 아무도 이를 구문 분석하지 않으므로 여기서 사이트를 중단시킬 수 없습니다.

.htaccess 없이도 작동하는 것

퍼머링크. WordPress 사이트가 Apache에서 .htaccess이 필요한 가장 일반적인 이유는 멋진 퍼머링크입니다. Kapsule에서는 재작성이 사이트의 서버 구성에 내장되어 있으므로 /2026/07/my-post/은 .htaccess 블록 없이 WordPress를 통해 확인됩니다. 퍼머링크가 404를 반환하는 경우 원인은 다른 것입니다. WordPress 퍼머링크 문제 해결을 참조하세요.

파일에 쓰는 WordPress. WordPress 및 일부 플러그인은 여전히 Apache를 가정하고 # BEGIN/# END 블록을 .htaccess에 씁니다. 이는 무해합니다. 파일은 실제이고, 쓰기 가능하며, 파일 관리자에서 볼 수 있습니다. 단순히 읽는 것뿐입니다.

"강화가 적용되었습니다"라고 보고하는 보안 플러그인. xmlrpc.php 또는 wp-config.php을 .htaccess를 편집하여 잠금했다고 주장하는 플러그인은 이 플랫폼에서 실제로 아무것도 보호하지 못했습니다. 사이트 자체의 Security 탭을 사용하세요. 이는 서버에서 동등한 규칙을 적용합니다.

일반적인 .htaccess 규칙에 대한 KPanel 동등한 설정

이들 각각은 사이트 자체에 있습니다: Websites, 그 다음 사이트, 그 다음 표시된 탭.

이 중 두 가지는 .htaccess 버전이 할 수 있는 것보다 더 많은 작업을 수행합니다. 리디렉션은 정확한 경로, 후행 슬래시 접두사 및 /blog/*과 같은 와일드카드를 지원하며, KPanel은 저장 후 리디렉션을 라이브로 검증합니다. 오류 페이지는 실제 상태 코드로 제공되므로, 사용자 정의 404 페이지는 양해의 말과 함께 200이 아닌 실제 404입니다.

파일 찾기 및 읽기

플러그인이 작성한 내용을 보거나 KPanel에서 규칙을 다시 만들기 전에 복사하기 위해 .htaccess을 살펴보고 싶을 수도 있습니다.

WordPress 탭에서

1. KPanel에 로그인하고 왼쪽 사이드바의 Websites를 클릭합니다.
2. 원하는 사이트를 클릭합니다.
3. WordPress 탭을 열고, wp-config 섹션을 엽니다.
4. .htaccess 패널로 스크롤합니다. 내용은 읽기 전용으로 표시되며, 변경해야 하는 경우 Edit 버튼이 있습니다.

파일 관리자에서

1. 사이트를 열고, Files, File Manager를 엽니다.
2. 도구 모음에서 Show Hidden을 클릭합니다. 점으로 시작하는 파일은 기본적으로 숨겨지므로 .htaccess은 이를 수행할 때까지 나타나지 않습니다.
3. .htaccess을 클릭하여 내장 편집기에서 엽니다.

파일은 wp-config.php 및 wp-content과 함께 사이트의 루트에 있습니다. 편집기 및 권한 컨트롤에 대한 전체 세부 정보는 파일 관리자 사용에 있습니다.

기본 WordPress 블록

참조용으로 이것이 WordPress가 자신을 위해 작성하는 블록입니다. Apache 호스트에서는 퍼머링크를 구동합니다. Kapsule에서는 비활성이고 삭제해도 아무것도 손상되지 않습니다:

# 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를 Advanced, Redirects에서 다시 만듭니다. 규칙당 한 행. 영구 이동의 경우 301을 선택하고, 변경이 반대로 될 수 있으면 302를 선택합니다.
2. HTTPS 강제 적용. 삭제합니다. 대신 사이트의 Settings에서 Force HTTPS를 켭니다.
3. IP 차단. WordPress, Security에서 IP 차단 패널에서 다시 만듭니다.
4. 캐싱 및 압축 헤더. 삭제합니다. 이는 자동으로 처리되며, 이전 호스트의 오래된 mod_expires 규칙은 혼란스러운 캐시 동작의 일반적인 원인입니다.
5. 플러그인이 작성한 모든 것. 무시합니다. 새 사이트에 플러그인을 다시 설치하고 자신의 것을 하도록 하세요.

마이그레이션은 파일 자체를 유지하므로 목록을 작업하는 동안 아무것도 손실되지 않습니다. 전체 마이그레이션 안내: cPanel에서 웹사이트 마이그레이션.

문제 해결

".htaccess에 리디렉션을 추가했는데 아무것도 안 됐습니다." 예상된 결과입니다. Advanced, Redirects에서 추가하세요. 거기의 Status 열은 리디렉션이 라이브로 검증되었는지 여부를 나타냅니다.

"플러그인이 사이트가 강화되었다고 말하는데 스캐너는 다릅니다." 플러그인이 읽지 않는 .htaccess 규칙을 작성했습니다. 사이트의 Security 탭에서 실제로 적용된 보호를 확인하세요.

"이전 호스트의 .htaccess에는 이해할 수 없는 규칙이 있었습니다." 무작정 복사하지 마세요. 파일을 첨부하여 티켓을 열고 Kapsule 동등한 규칙이 있는 것과 공유 Apache 호스트의 부족함을 보완하는 것뿐인 규칙을 알려드리겠습니다.

"퍼머링크가 손상되었습니다." 이것은 여기서 .htaccess 문제가 아닙니다. WordPress 퍼머링크 문제 해결로 이동하거나, 사이트의 WordPress 탭에서 재작성 규칙을 플러시한 다음 Quick Actions, Flush Rewrites로 이동합니다.