라이믹스 업데이트 후 접속 안 될 때 SSH·FTP 캐시 삭제와 HTTPS 강제 설정 해결방법

잡가이버 2026. 6. 1. 13:49

라이믹스 업데이트를 하다 보면 파일은 정상적으로 올린 것 같은데 사이트가 안 열리거나, 관리자 페이지 접속이 꼬이거나, HTTP로 접속했는데 계속 HTTPS로 넘어가는 경우가 있습니다. 저도 비슷한 상황에서 FTP로 업데이트 파일을 올리고 SSH에서 캐시를 지우는 과정까지 진행했는데요. 처음에는 단순 캐시 문제인 줄 알았지만, 실제로는 업로드 경로 확인, 캐시 삭제 명령어, .htaccess, 라이믹스 DB의 HTTPS 강제 설정까지 같이 봐야 하는 상황이었습니다.

특히 라이믹스는 워드프레스처럼 관리자에서 버튼 하나 누르면 자동으로 끝나는 구조라기보다, 서버에 직접 파일을 덮어쓰고 관리자에서 DB 업데이트와 캐시 재생성을 해줘야 하는 방식에 가깝습니다. 그래서 FTP 경로를 잘못 잡거나, files 폴더를 건드리거나, SSH 명령어를 한 글자만 잘못 입력해도 생각보다 당황스러운 오류가 나올 수 있습니다.

바로 봐야 할 부분
라이믹스 업데이트 후 접속이 안 된다면 먼저 FTP에서 업데이트 파일이 실제 설치 경로에 올라갔는지 확인하고, SSH에서 files/cache를 삭제한 뒤 관리자 페이지에서 DB 업데이트와 캐시 재생성을 해야 합니다. 그래도 HTTPS로 강제 이동되면 .htaccess 또는 DB의 rx_domains / xe_domains 설정을 확인해야 합니다.

라이믹스 공식 사이트 바로가기 라이믹스 설치 환경 확인

라이믹스 업데이트 파일은 어디에 올려야 할까?

FTP를 열어보면 로컬에는 라이믹스 업데이트 파일이 있고, 서버에는 기존 사이트 파일이 있습니다.

이때 중요한 건 서버의 아무 폴더에나 올리는 게 아니라 기존 라이믹스가 설치된 루트 경로에 덮어써야 한다는 점입니다.

예를 들어 서버에서 아래와 같은 폴더가 보이면 이 위치가 라이믹스 루트입니다.

addons
classes
common
config
files
layouts
modules
widgets
widgetstyles
index.php

실제 호스팅 환경에서는 경로가 보통 아래 중 하나로 잡히는 경우가 많습니다.

서버 환경	가능한 설치 경로 예시	확인 포인트
일반 웹호스팅	/www/xe	XE 또는 Rhymix가 하위 폴더에 설치된 경우
public_html 기반 호스팅	/home/계정명/public_html	도메인 루트에 바로 설치된 경우
서브폴더 설치	/home/계정명/public_html/xe	주소 뒤에 /xe가 붙는 경우

FTP에서 오른쪽 원격 사이트 경로가 /www/xe처럼 보이고, 그 안에 files, addons, modules, layouts, index.php가 있다면 그 위치가 업데이트 파일을 넣어야 하는 곳입니다.

업데이트 파일 중 넣을 것과 빼도 되는 것

라이믹스 업데이트 파일을 받으면 여러 폴더와 문서 파일이 같이 들어 있습니다.

대부분의 코어 폴더는 기존 사이트에 덮어써야 하지만, 문서 파일은 사이트 작동에 직접 필요하지 않아서 빼도 됩니다.

항목	업로드 여부	설명
addons	업로드	기본 애드온 파일 갱신
classes	업로드	라이믹스 코어 클래스 파일
common	업로드	공통 코어 파일
config	업로드	기본 설정 관련 코어 파일
layouts, m.layouts	업로드	기본 레이아웃 갱신. 커스텀 레이아웃은 병합 방식이면 유지됨
modules	업로드	게시판, 회원, 관리자 등 핵심 모듈 갱신
widgets, widgetstyles	업로드	기본 위젯 파일 갱신
index.php	업로드	진입 파일이므로 최신 파일로 교체
.htaccess	주의해서 업로드	기존 리다이렉트, HTTPS 강제, 보안 설정이 있으면 먼저 백업 후 비교
README.md, LICENSE, SECURITY.md 등	빼도 됨	문서 파일이라 사이트 작동에는 직접 필요 없음

절대 하면 안 되는 것
기존 서버 파일을 전부 삭제한 뒤 새 파일만 업로드하면 안 됩니다. 특히 files 폴더는 첨부파일, 캐시, 설정 파일이 들어있는 중요한 폴더라서 삭제하면 사이트가 크게 망가질 수 있습니다. FTP에서는 “삭제 후 업로드”가 아니라 기존 폴더 위에 병합 덮어쓰기로 진행해야 합니다.

FileZilla에서 꼭 확인해야 하는 부분

FTP 업로드가 끝났다고 바로 안심하면 안 됩니다. FileZilla 하단에 보면 전송 성공, 전송 실패, 대기 파일 탭이 있는데요.

라이믹스 업데이트 중 일부 PHP 파일이 실패로 남아 있으면 사이트가 부분적으로 깨지거나 관리자 화면에서 오류가 날 수 있습니다.

업로드 후에는 아래처럼 확인하는 게 좋습니다.

FileZilla 하단의 전송 실패 탭 클릭
실패 파일이 있으면 전체 선택
마우스 오른쪽 클릭
다시 대기열에 넣기 선택
전송 재시작

라이믹스는 파일 수가 많다 보니 네트워크가 잠깐 끊기거나 권한 문제로 일부 파일이 누락되는 경우가 있습니다. 겉으로는 업로드가 끝난 것처럼 보여도 전송 실패 탭에 파일이 남아 있으면 실제 업데이트는 덜 된 상태입니다.

SSH에서 캐시 삭제할 때 자주 하는 실수

라이믹스 업데이트 후에는 files/cache 안의 캐시를 삭제해주는 게 좋습니다.

그런데 SSH 명령어를 입력할 때 가장 흔한 실수가 rm -rf를 잘못 입력하는 겁니다.

예를 들어 아래처럼 입력하면 제대로 삭제되지 않습니다.

rm 0rf files/cache/*
rm -rt files/cache/*
rm files/cache/*

첫 번째는 숫자 0을 입력한 것이고, 두 번째는 옵션이 잘못된 것이고, 세 번째는 폴더를 삭제할 수 없어서 디렉터리입니다라는 메시지가 나옵니다. 캐시 폴더 안에는 파일뿐 아니라 여러 하위 디렉터리가 있기 때문에 재귀 삭제 옵션이 필요합니다.

정확한 명령어는 아래입니다.

cd /www/xe
pwd
rm -rf files/cache/*
ls -al files/cache

pwd 명령어를 쳤을 때 라이믹스 설치 경로가 나와야 합니다. 예를 들어 사이트가 /www/xe에 설치되어 있다면 아래처럼 나오는 게 정상입니다.

/www/xe

그 상태에서 rm -rf files/cache/*를 실행했는데 아무 메시지 없이 프롬프트가 다시 나온다면 대부분 정상적으로 삭제된 겁니다. 리눅스는 명령어가 성공했을 때 친절하게 “성공했습니다”라고 알려주지 않는 경우가 많습니다.

캐시 삭제가 잘 됐는지 확인하는 명령어

ls -al files/cache

결과가 거의 비어 있거나, 점 하나와 점 두 개만 보이면 캐시가 비워진 상태로 보면 됩니다.

service 명령어가 안 먹히는 이유

업데이트 후 PHP를 재시작하려고 아래처럼 입력하는 경우가 있습니다.

service php8.4-fpm restart

그런데 웹호스팅 SSH에서는 아래처럼 나올 수 있습니다.

service: command not found

이건 서버가 고장 났다는 뜻이 아니라, 현재 접속한 계정이 서버 전체를 관리하는 root 권한이 아니거나 웹호스팅 환경에서 service 명령어를 제공하지 않는다는 뜻입니다. 일반 호스팅에서는 사용자가 PHP-FPM이나 Apache를 직접 재시작하지 못하는 경우가 많습니다.

이럴 때는 서버 재시작보다 아래 작업이 현실적으로 더 중요합니다.

files/cache 삭제
관리자 페이지에서 캐시파일 재생성
관리자 메뉴 캐시 재생성
브라우저 시크릿 모드로 접속 테스트
호스팅 관리자 페이지에서 PHP 버전 확인

캐시를 지워도 안 되면 HTTPS 강제 설정을 봐야 합니다

캐시를 삭제했는데도 사이트가 계속 안 열리거나, HTTP 주소로 접속했는데 HTTPS로 강제 이동된다면 단순 캐시 문제가 아닐 가능성이 큽니다. 이때는 크게 두 군데를 봐야 합니다.

확인 위치	문제 원인	해결 방향
.htaccess	Apache 리다이렉트 규칙으로 HTTPS 강제	HTTPS 관련 RewriteRule 주석 처리 또는 제거
DB 도메인 테이블	라이믹스 관리자에서 SSL 항상 사용 설정	rx_domains 또는 xe_domains의 security 값을 none으로 변경
브라우저	이전 301 리다이렉트나 HSTS 캐시	시크릿 모드 또는 다른 브라우저로 테스트

먼저 SSH에서 리다이렉트 상태 확인하기

사이트가 실제로 HTTPS로 튕기는지 확인하려면 SSH에서 아래 명령어를 입력합니다. 도메인은 본인 사이트 주소로 바꾸면 됩니다.

curl -I http://example.com/xe/

결과에 아래처럼 Location: https://...가 보이면 HTTP 접속이 HTTPS로 리다이렉트되고 있는 상태입니다.

Location: https://example.com/xe/

.htaccess에서 HTTPS 강제 코드 찾기

라이믹스 루트에서 아래 명령어를 입력하면 .htaccess 안에 HTTPS 관련 코드가 있는지 빠르게 찾을 수 있습니다.

grep -nEi "https://|HTTPS|443|Strict-Transport-Security" .htaccess

아래와 비슷한 코드가 있다면 .htaccess에서 HTTPS를 강제로 보내고 있을 수 있습니다.

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

수정은 nano 편집기로 할 수 있습니다.

nano .htaccess

해당 줄 앞에 #을 붙이면 임시로 주석 처리됩니다.

# RewriteCond %{HTTPS} off
# RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

저장은 아래 순서로 하면 됩니다.

Ctrl + O
Enter
Ctrl + X

라이믹스 DB에서 SSL 항상 사용 끄기

.htaccess에 문제가 없는데도 계속 HTTPS로 넘어간다면 라이믹스 관리자에서 설정한 SSL 항상 사용 값이 DB에 남아 있을 수 있습니다. 이때는 DB의 도메인 테이블을 직접 확인해야 합니다.

먼저 DB 접속 정보는 라이믹스 설정 파일에서 확인할 수 있습니다.

cat files/config/db.config.php

여기에서 DB 아이디, DB명, DB 비밀번호를 확인한 뒤 MySQL에 접속합니다.

mysql -u DB아이디 -p DB이름

비밀번호를 입력한 뒤 도메인 테이블을 찾습니다.

show tables like '%domains%';

라이믹스 버전이나 XE에서 이전한 환경에 따라 보통 아래 둘 중 하나가 나옵니다.

rx_domains
xe_domains

rx_domains가 있다면 아래 명령어를 실행합니다.

update rx_domains set security='none';

xe_domains가 있다면 아래 명령어를 실행합니다.

update xe_domains set security='none';

변경됐는지 확인하려면 아래처럼 조회합니다.

select domain, security from rx_domains;

또는 XE 테이블이면 아래처럼 확인합니다.

select domain, security from xe_domains;

값이 none으로 바뀌었다면 MySQL을 종료합니다.

exit;

마지막으로 캐시를 다시 지웁니다.

rm -rf files/cache/*

주의할 점
DB 값을 직접 수정하기 전에는 반드시 DB 백업을 먼저 해두는 게 좋습니다. 특히 운영 중인 사이트라면 단순히 명령어만 보고 따라 하기보다, 현재 테이블명이 rx_domains인지 xe_domains인지 확인한 뒤 진행해야 합니다.

접속 테스트는 일반 창보다 시크릿 모드가 낫습니다

HTTPS 강제 설정을 껐는데도 일반 브라우저에서 계속 HTTPS로 이동하는 경우가 있습니다. 이건 서버 설정이 아직 남아 있어서가 아니라 브라우저가 예전에 받은 301 리다이렉트나 HSTS 정보를 기억하고 있어서 그럴 수 있습니다.

그래서 수정 후에는 아래 방식으로 테스트하는 게 좋습니다.

크롬 시크릿 모드
엣지 InPrivate 창
스마트폰 모바일 데이터 접속
다른 브라우저
SSH에서 curl -I 명령어 확인

서버에서는 이미 HTTP로 정상 응답하는데 내 PC에서만 계속 HTTPS로 넘어간다면 브라우저 캐시 문제일 가능성이 큽니다.

업데이트 후 관리자에서 해야 하는 작업

파일 업로드와 SSH 캐시 삭제가 끝났다면 관리자 페이지에 접속해서 마무리 작업을 해야 합니다. 라이믹스는 파일만 바꿨다고 업데이트가 완전히 끝나는 구조가 아니기 때문입니다.

관리자 페이지에 들어가면 아래 항목을 확인합니다.

DB 업데이트 알림이 있는지 확인
모듈 업데이트 알림이 있는지 확인
업데이트 버튼 실행
캐시파일 재생성
관리자 메뉴 캐시 재생성
게시판 목록 확인
글쓰기 테스트
댓글 작성 테스트
파일 첨부 테스트
모바일 화면 확인

특히 오래된 스킨이나 XE 시절부터 쓰던 애드온이 있다면 업데이트 직후 오류가 날 수 있습니다. 이럴 때는 코어 문제인지, 애드온 문제인지, 스킨 문제인지 나눠서 봐야 합니다.

상황별로 보면 이렇게 판단하면 됩니다

증상	가능성 높은 원인	먼저 해볼 것
업데이트 후 흰 화면	캐시, PHP 버전, 누락 파일, 오래된 애드온	전송 실패 확인 후 files/cache 삭제
HTTP 접속 시 HTTPS로 이동	SSL 항상 사용, .htaccess 리다이렉트	curl -I 확인, .htaccess와 DB security 값 확인
rm 명령어에서 디렉터리입니다 표시	-r 옵션 없이 폴더 삭제 시도	rm -rf files/cache/* 사용
service command not found	웹호스팅 일반 계정 권한 제한	PHP 재시작 대신 캐시 삭제와 관리자 캐시 재생성
관리자 페이지 일부 오류	업데이트 파일 일부 누락	FileZilla 전송 실패 탭 확인 후 재업로드

라이믹스 업데이트 전후 체크리스트

업데이트 전

파일 전체 백업, DB 백업, files 폴더 백업, .htaccess 백업을 먼저 해둡니다.

FTP 업로드

기존 라이믹스 루트에 병합 덮어쓰기 방식으로 업로드합니다. files 폴더는 삭제하지 않습니다.

SSH 확인

pwd로 경로를 확인하고 rm -rf files/cache/* 명령어로 캐시를 삭제합니다.

접속 오류

HTTPS 강제 이동이 있으면 .htaccess와 DB 도메인 테이블의 security 값을 확인합니다.

자주 헷갈리는 부분

업데이트 파일을 기존 폴더에 다 넣어도 되나요?

대부분 넣어도 됩니다. 다만 README.md, LICENSE, SECURITY.md 같은 문서 파일은 사이트 작동에 직접 필요하지 않으니 빼도 됩니다. .htaccess는 기존에 직접 넣은 리다이렉트나 보안 설정이 있을 수 있으니 백업 후 비교하는 게 좋습니다.

files 폴더도 새 파일로 덮어써야 하나요?

보통 업데이트 파일에는 files 폴더가 없거나, 있더라도 기존 files 폴더를 삭제하면 안 됩니다. files 폴더에는 첨부파일, 캐시, 설정 파일 등이 들어갈 수 있어서 사이트 운영 데이터와 직접 연결됩니다.

rm -rf files/cache/* 실행했는데 아무 메시지가 안 나오면 실패인가요?

아닙니다. 리눅스는 명령어가 정상 실행되면 아무 메시지 없이 끝나는 경우가 많습니다. 확인하려면 ls -al files/cache 명령어로 안쪽이 비어 있는지 보면 됩니다.

SSH에서 PHP-FPM 재시작을 못 하면 어떻게 하나요?

일반 웹호스팅 계정에서는 service나 systemctl 명령어가 막혀 있는 경우가 많습니다. 이 경우 PHP-FPM 재시작보다 라이믹스 캐시 삭제, 관리자 캐시 재생성, 브라우저 캐시 초기화, 호스팅 관리자 페이지에서 PHP 버전 확인을 먼저 보는 게 현실적입니다.

HTTPS 설정을 껐는데도 계속 HTTPS로 접속됩니다

.htaccess에 HTTPS 강제 코드가 남아 있거나, DB의 rx_domains 또는 xe_domains 테이블에 security 값이 always로 남아 있을 수 있습니다. 서버 설정을 바꾼 뒤에도 브라우저 캐시 때문에 계속 HTTPS로 보일 수 있으니 시크릿 모드로 다시 확인하는 게 좋습니다.

마무리하면서
라이믹스 업데이트는 파일만 덮어쓴다고 끝나는 작업이 아닙니다. FTP에서는 정확한 설치 경로와 전송 실패 여부를 확인해야 하고, SSH에서는 캐시 삭제 명령어를 정확히 입력해야 합니다. 그래도 접속이 안 된다면 .htaccess와 DB의 HTTPS 강제 설정까지 봐야 합니다. 특히 운영 중인 사이트라면 업데이트 전 파일과 DB 백업을 먼저 해두고, 가능하면 테스트 폴더나 서브도메인에서 먼저 확인한 뒤 실제 사이트에 반영하는 게 가장 안전합니다.

그리드형

저작자표시 비영리 변경금지 (새창열림)