인증서 오류 없이 non-www에서 www로 전환

지원 자체 호스팅
1

커뮤니티 여러분,

현재 다음과 같은 문제를 겪고 있으며, 적절한 해결 방법을 찾는 데 도움을 주실 분이 계신다면 정말 감사하겠습니다.

  1. Vultr의 Ubuntu 21.10 서버에 discourse를 설치했습니다.
  2. 기본 설정을 따랐고, 설치 과정에서 www.example.com에 대한 let’s encrypt 인증서를 이미 생성했습니다.

제 목표는 포럼이 example.com이 아닌 www(www.example.com)를 통해서만 접근 가능하도록 하는 것입니다.

현재 상황:
→ http://example.com은 올바르게 https://www.example.com으로 리다이렉트(301)됩니다.
→ http://www.example.com은 올바르게 https://www.example.com으로 리다이렉트(301)됩니다.
→ https://example.com은 인증서 오류를 발생시키며, 올바른 https://www.example.com으로 리다이렉트되지 않습니다(인증서는 www.example.com에 발급되었지 example.com에는 발급되지 않았습니다).

https://example.com이 https://www.example.com으로 리다이렉트되도록 하는 가장 좋은 방법은 무엇이며, 제 목표를 어떻게 달성할 수 있을까요?

감사합니다.
Elmi

2

이 조언을 따라 app.yml 파일에 한 줄을 추가했습니다:

루트 도메인이나 www 서브도메인으로 저를 찾는 데 문제가 없으므로, 리다이렉트 설정은 시도해 보지 않았습니다.

3

검색 엔진에서 중복 콘텐츠가 발생하지 않도록 주의하세요.

4

이 부분은 내가 그렇게 잘 아는 분야는 아니에요. :slightly_smiling_face: 추천하는 방법은 무엇인가요? 현재 도메인과 www 서브도메인 모두에 A 레코드를 설정해 두었는데, 둘 다 제 Digital Ocean Droplet으로 해석됩니다.

5

가장 쉬운 방법은 www.forcewww.com을 사용하는 것입니다. (면책 조항: 이 서비스는 제가 직접 운영하는 것입니다)

6

@JammyDodger 님, 피드백 주셔서 정말 감사합니다. 약간 다른 문제를 다루는 것 같아 보이지만, 그래도 한번 시도해 볼게요. 어쩌면 잘 될지도 모르니까요.

사이트는 한 버전만 유지하는 것이 최선의 방법입니다. Duplicate Content: Why does it happen and how to fix issues - Moz

7

이러한 리다이렉트는 모든 웹 서버에서 매우 자명한 작업이며, 검색만 해봐도 방법을 알 수 있습니다. 그런데 왜 여기서는 다른가요?

8

두 인증서를 모두 요청하면 원하는 대로 리디렉션될 것이라고 꽤 확신합니다. forcewww.com 솔루션이 더 쉽습니다.

왜냐하면 Docker 컨테이너 내부에 있기 때문에, 다른 곳에서 찾아볼 수 있는 호스트 내부 솔루션은 아마도 도움이 되지 않을 것이기 때문입니다.

9

간단히 업데이트를 공유합니다. 제가 해결한 방법을 알려드리려고 합니다.

시도해 보았지만, 제 환경에서는 작동하지 않았습니다. 추가 인증서가 발급되지 않은 것으로 보였습니다.

또한 이 제안에 따라 문제를 해결해 보았지만, 이것도 제 환경에서는 작동하지 않았습니다.

현재까지 제 문제를 해결해 준 유일한 방법은 여기의 지침을 따르는 것이었습니다. http://www.forcewww.com/

그러나 외부 서비스에 의존해야 하므로 여전히 바람직한 해결책은 아니라고 생각합니다. 물론 무료이지만, 해당 서비스가 중단되면 새로운 해결책을 찾아야 합니다.
@michaeld 님, 오해하지 마세요. 님이 제안해 주신 방법은 정말 훌륭하고 간편하며, 깊이 감사드립니다.

표준 설치 과정에서 www 버전 또는 non-www 버전 중 하나만 선택할 수 있도록 결정할 수 있다면 우리의 삶을 조금 더 편하게 만들어 줄 수 있을 텐데, 그렇게 할 수 있다면 정말 좋겠습니다. :slight_smile:

10

최근 한 달 동안은 테스트하지 않았지만, 확실히 작동한다고 생각합니다. DNS를 올바르게 설정하지 않은 채 여러 번 실행했다면 속도 제한(rate limit)이 걸렸을 가능성이 큽니다.

"두 호스트명으로 인증서를 요청하는 것"을 말씀하시는 건가요? 그건 너무 어렵습니다. 그렇게 DNS를 설정하는 방법을 모르는 많은 사용자에게 문제가 발생할 가능성이 매우, 매우 높습니다.

11

에이펙스 도메인과 www 버전 모두에 대한 인증서를 생성하면 두 가지를 모두 커버할 수 있습니다. :smiley 말씀하신 대로 해당 인증서에는 에이펙스 도메인이 포함되어 있지 않아서 오류가 발생하는 것입니다.

리다이렉트는 다음과 같이 설정해야 합니다:

  • http://example.com → https://example.com
  • http://www.example.com → https://www.example.com
  • 그리고 https://example.com → https://www.example.com(선호하는 도메인)으로 리다이렉트합니다.

이렇게 하면 사용자가 에이펙스 도메인이나 www 버전 중 어느 것을 입력하든 오류 없이 https://www.example.com에 도달하게 됩니다. 에이펙스와 www를 모두 인증서에 포함시키는 것이 모범 사례입니다. 서버에서 제공되는 인증서가 수정된/새로운 인증서인지, 아니면 이전 인증서인지 꼭 확인하세요.

12

아, 그렇군요. 언급해 주시니 이제 기억나기 시작하네요 — 제가 Discourse를 ‘일반적인’ Nginx 뒤에 배치한 두 번째 이유가 바로 그것이었어요. 첫 번째 이유는 몇 가지 필터링을 해야 했기 때문이었죠. 글쎄요, 제 솔루션은 화려하거나 기술적으로 까다롭지는 않지만, 이 커뮤니티에서는 그렇게 인기 있는 방식은 아닌 것 같아요.

솔직히 말해서, 이렇게 정말 사소한 일을 제3자 웹 서비스를 통해 해야 한다면 Docker는 사용자 친화적이지 않은 솔루션이라고 생각합니다. 그렇지 않다면 Docker는 분명 매우 유용할 거라 생각하는데, 그렇게 인기가 많아지지 않았다는 점이 의외입니다.

13

고려해 주셔서 감사합니다 @pfaffman. 이번 주말에 다시 시도해 보겠습니다.

두 번째 주제에 대해서는 말씀하신 뜻을 이해합니다. 하지만 동일한 콘텐츠가 오직 하나의 도메인을 통해서만 접근 가능해야 한다는 점이 매우 중요하므로, 고급 설정이나 선택 사항으로 제공되는 것이 좋을 것 같습니다.

14

실제로는 그렇지 않습니다(Discourse 자체가 작동하지 않는 경우를 제외하고는). 하지만 SEO와 구글을 염두에 두고 말씀하시는 것이라면, 서브도메인 문제는 이미 오래전부터 그렇게 심각한 문제가 아니었습니다. 구글은 이를 잘 처리할 수 있는데, 실제 도메인은 하나뿐이기 때문입니다. 하나는 스텁(stub)에 가까운 FQDN이고, 다른 하나는 www가 붙은 실제 도메인입니다.