아마존 AWS: ERR_INVALID_REDIRECT 오류 원인 및 해결 방법

아마존 AWS에서 호스팅 중인 워드프레스 사이트를 카페24로 이전하는 작업을 의뢰받았습니다. 사이트를 살펴보니 ERR_INVALID_REDIRECT 오류가 발생하면서 사이트에 접속이 되지 않았습니다. 먼저는 사이트 접속 문제를 해결한 후에 데이터와 DB를 백업받아서 카페24로 이전하기로 했습니다.

Amazon AWS: ERR_INVALID_REDIRECT 오류 원인 및 해결 방법

아마존 AWS에서 호스팅되고 있는 사이트에 접속하니 아래와 같이 ERR_INVALID_REDIRECT 에러가 발생했습니다.

이 오류는 여러 가지 원인으로 인해 발생할 수 있다고 합니다.

1. 잘못된 서버 주소 설정: 서버의 주소 설정이 올바르지 않으면 ERR_INVALID_REDIRECT 오류가 발생할 수 있습니다. 예를 들어, RStudio Connect를 사용하는 경우 /etc/rstudio-connect/rstudio-connect.gcfg 파일의 Server.Address 값이 정확해야 합니다. 이 값은 사용자가 서버와 상호 작용하는 "프론트 도어"로, 보안 및 기타 이유로 Connect의 특정 부분이 이 값에 의존합니다. 따라서 서버 주소가 잘못 설정되면 리디렉션 오류가 발생할 수 있습니다.
2. HTTPS 인증서 문제: HTTPS 요청에 사용된 도메인 이름이 리스너의 ACM(AWS Certificate Manager) 인증서에 지정된 대체 이름과 일치하지 않으면 인증서 이름 불일치 오류가 발생할 수 있습니다. 브라우저는 TLS/SSL 인증서의 도메인 이름(FQDN)이 주소 표시줄의 도메인 이름과 일치하지 않으면 연결을 중단하고 이름 불일치 오류를 표시합니다. 이는 사용자의 신뢰를 떨어뜨리고 웹사이트 방문을 꺼리게 만들 수 있습니다. 따라서 TLS/SSL 인증서를 주문할 때 인증서의 도메인 이름이 브라우저 주소 표시줄의 웹사이트 도메인 이름과 정확히 일치해야 합니다.
3. 리디렉션 설정 오류: 리디렉션(리다이렉트) 규칙이 잘못 설정되면 무한 루프에 빠질 수 있습니다. 예를 들어, AWS Elastic Load Balancer(ELB)와 Varnish, Apache를 함께 사용할 때 HTTPS 리디렉션 설정이 잘못되면 Apache 로그에 "무한 루프" 오류가 나타날 수 있습니다. 이는 내부 리디렉션 제한을 초과하는 문제로, 구성 오류로 인한 것일 수 있습니다. 이를 해결하기 위해서는 Varnish 구성을 수정하거나, ALB에서 직접 HTTP를 HTTPS로 리디렉션하도록 설정할 수 있습니다.
4. 보안 그룹 설정 문제: AWS 보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 필요한 포트에 대한 트래픽이 허용되지 않으면 ERR_INVALID_REDIRECT 오류가 발생할 수 있습니다. 보안 그룹 규칙은 프로토콜, 포트 범위, IP 또는 IP 그룹을 지정하여 트래픽을 제어합니다. 최소 권한 원칙에 따라 보안 그룹을 구성해야 하며, 불필요하게 광범위한 인바운드 트래픽을 허용하는 것은 보안 위험을 초래할 수 있습니다. 따라서 보안 그룹 설정을 주기적으로 감사하고, 사용하지 않는 보안 그룹은 삭제하며, 다른 목적을 가진 인스턴스에 대해서는 개별적인 보안 그룹을 생성하는 것이 좋습니다.

해당 사이트의 경우 SSL 인증서 오류로 인해 이 리디렉션 오류가 발생하는 것으로 추정되었습니다.

인증서가 2025년 2월 3일에 만료되었기 때문에 아마도 2월 3일 인증서 만료 후부터 이 문제가 발생하지 않았나 생각됩니다.

문제의 원인을 파악했으므로 서버에 접속하여 만료된 SSL 인증서를 갱신하면 문제가 해결될 것으로 판단되었습니다. 문제는 사이트 운영하시는 분이 SSH에 접속하는 방법에 대하여 모르고 있었습니다. 서버 관리를 담당하던 개발자가 퇴사하면서 서버나 홈페이지에 대해 잘 모르는 분이 담당하고 계셨습니다.

어떻게 하여 겨우 SSH에 접속하여 SSL 인증서 문제를 해결할 수 있었습니다. 아마존 AWS에 로그인하여 EC2 » 인스턴스에서 현재 실행 중인 인스턴스에 대한 자세한 정보를 확인할 수 있습니다.

아마존 AWS에서 SSH에 접속하는 방법은 다음 영상을 참고할 수 있습니다.

조금 긴 영상이지만 초보자도 처음부터 천천히 시청하면 SSH에 접속이 가능할 것입니다.

사이트가 워드프레스로 제작되었는지 확인하는 방법

AWS에서 사이트 접속 문제가 해결되어 이제 사이트를 카페24로 이전하는 작업을 수행해야 했습니다. 하지만 사이트를 아무리 살펴보아도 워드프레스로 제작된 것으로 보이지 않았습니다.

일반적으로 사이트가 워드프레레스로 제작되었는지 여부는 다음과 같은 간단한 방법으로 확인이 가능합니다.

1. 사이트주소/wp-admin이나 사이트주소/wp-login.php 페이지에 접속이 된다면 워드프레스로 제작된 것입니다. 하지만 로그인/관리자 페이지 URL을 숨기는 경우가 있습니다.
2. 페이지 소스에서 wp-content를 검색해보면 워드프레스로 만들어졌는지 알 수 있습니다. 워프로 제작되었다면 wp-content가 검색될 것입니다.

해당 사이트이 페이지 소스를 챗GPT에 넣어 물어보니 Next.js 프레임워크 기반으로 제작된 것으로 보인다는 답변을 받았습니다. 다음의 경우에는 Next.js 프레임워크로 제작된 것으로 추정할 수 있다고 합니다.

1. /_next/static/ 폴더 및 /_next/static/chunks/ 스크립트 파일 존재
   • Next.js는 정적 파일 및 번들된 자바스크립트 파일을 /_next/static/ 경로에 저장합니다.
   • /_next/static/chunks/ 경로를 보면 여러 개의 번들된 JS 파일이 로드되고 있습니다.
2. next-size-adjust 메타 태그
   • Next.js의 최적화 기능 중 하나인 next-size-adjust가 사용됨.
3. 서버사이드 렌더링(SSR) 및 정적 사이트 생성(SSG) 가능성
   • Next.js는 SSR과 SSG를 모두 지원하는데, initialCanonicalUrl 등의 메타데이터가 이를 시사합니다.
4. 페이지 구조 및 라우팅
   • /_next/static/chunks/app/(menu-header)/contact/page-***.js 파일을 보면 동적 라우팅(pages 또는 app 디렉터리 기반의 라우팅)이 사용되었음을 알 수 있습니다.

Next.js는 리액트(React) 기반의 강력한 프레임워크입니다.

Next.js는 React 기반의 강력한 웹 프레임워크로, 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하여 웹 애플리케이션 개발을 간소화합니다. Vercel에서 개발된 이 프레임워크는 자동 코드 분할, 파일 기반 라우팅, API 라우트 지원 등 다양한 기능을 제공하여 개발자의 생산성을 높이고 애플리케이션의 성능을 최적화합니다.

Next.js의 주요 특징으로는 서버 사이드 렌더링을 통한 초기 로딩 속도 개선, 검색 엔진 최적화(SEO) 향상, 그리고 풀스택 개발 능력을 들 수 있습니다. 또한 Hot Module Replacement(HMR)를 지원하여 개발 경험을 개선하고, 자동 페이지 라우팅을 통해 개발 프로세스를 간소화합니다. 이러한 기능들로 인해 Next.js는 대규모 상용 애플리케이션부터 소규모 웹사이트까지 다양한 프로젝트에 즉시 적용할 수 있는 인기 있는 프레임워크로 자리 잡았습니다.

클라이언트는 해당 사이트가 워드프레스로 제작되었는지, 아니면 Next.js 플레임워크 기반으로 제작되었는지 여부를 알지 못한 상태에서 인수인계를 받았던 것 같습니다.

아마존 AWS/Vultr vs. 클라우드웨이즈

저는 Vultr에서 워드프레스를 운영해 본 경험이 있지만 서버 관리가 쉽지 않아서 지금은 모든 사이트를 클라우드웨이즈(Cloudways)라는 클라우드 호스팅에서 관리하고 있습니다. 하나의 서버에 10개 정도의 애플리케이션(워드프레스)이 설치되어 있고, 일부는 멀티사이트라서 실제 운영하는 워드프레스 사이트는 20개가 넘습니다.

1개 사이트를 운영한다면 아마존 AWS나 Vultr도 괜찮은 선택 같습니다. 서버를 운영하다 서버 오류가 발생하면 서버(인스턴스)를 날리고 새로운 서버를 생성한 후에 워드프레스를 복원할 수 있습니다. 이 경우 항상 백업을 하여 백업 파일을 PC나 클라우드 스토리지에 보관하고 있다가 문제 발생 시 백업본을 사용하여 복구가 가능합니다.

하지만 10개가 넘는 사이트를 하나의 서버에서 운영하는 경우 서버 장애가 발생하면 난감하지 않을 수 없습니다. 서버 문제를 해결할 때까지 모든 사이트의 접속이 불가능하게 되고, 새로운 서버를 만들어 이전하려고 해도 10개가 넘는 사이트를 이전하는 것은 많은 시간과 노력이 들고, 사이트에 접속하지 못하는 문제로 인한 피해가 크므로 저는 AWS나 Vultr 서버를 쉽게 관리할 수 있는 클라우드웨이즈에서 모든 사이트를 관리하고 있습니다.

서버 관리에 자신이 있는 경우 Vultr 등을 이용해도 좋을 것 같습니다. 리눅스 서버에 대하여 잘 모르는 경우에는 그리 권장하지 않습니다. 실제로 서버에 대하여 모르는 상태에서 AWS, Vultr 등에서 서버를 운영하다가 서버 문제로 인해 많은 스트레스를 겪는 분들이 계십니다. 서버 문제를 수리하기 위해 많은 비용을 들여 전문가를 고용하거나 비용 때문에 사이트를 포기하는 안타까운 사례도 간혹 접합니다.

📍 클라우드웨이즈 할인 프로모 코드 & 가입 방법 (45% 쿠폰)

가성비 좋은 호스팅을 원하는 경우에는 블루호스트와 비슷한 수준의 케미클라우드(ChemiCloud)를 고려할 수 있습니다. 케미는 작년 7월에 서울 서버를 도입하여 우리나라에서도 속도가 빠릅니다.

💚서울 서버를 제공하는 ChemiCloud 워드프레스 호스팅 가입 방법 및 워드프레스 설치

참고

https://avada.tistory.com/3616

케미클라우드 워드프레스 백업 & 복원 방법 (feat. 무료 일일 백업 & 복원 기능)

https://avada.tistory.com/3566

아마존 AWS에서 클라우드웨이즈로 워드프레스 멀티사이트 이전 작업

https://avada.tistory.com/2897

엘리멘터 무료 버전 vs. 프로 버전 비교