잠깐… 이제 알 것 같아… 프록시를 비활성화하고 클라우드플레어 템플릿 없이 다시 빌드했어. 그리고 나서 다시 프록시를 활성화했더니, 엄격한 SSL 설정으로 워드프레스와 포럼에 접근할 수 있어!
Cloudflare 템플릿을 사용하지 않으면 매우 쉽게 속도 제한에 걸릴 수 있습니다…
Discourse는 많은 사용자가 동일한 IP(Cloudflare 프록시)를 통해 가입한다고 판단하여 속도 제한을 시작할 것입니다.
음… 그럼 letsencrypt 이메일 없이 cloudflare 템플릿으로 다시 해보는 게 나을 것 같네요. cloudflare 템플릿으로 다시 빌드할 때 프록시를 활성화한 채로 두어야 할까요?
도와주셔서 정말 감사합니다… 저는 사실 더 창의적인 쪽에 가까운 사람이라서요.
이건 DNS가 아니라 제 도메인 등록 업체예요… 다른 DNS를 사용하려면 업체에서 요구하는 거액의 비용을 감당할 수 없거든요. 그래서, 어쩔 수 없네요.
Discourse 설정에서는 이제 인증서를 등록할 때 이메일이 필요하지 않으며, 이미 한동안 그렇게 되어 있었습니다. yml 파일을 수정하여 SSL을 비활성화하지 않는 한, 기본적으로 항상 HTTPS가 적용됩니다.
Cloudflare를 DNS로 사용하는 것과 오렌지 구름(프록시)을 켜는 것은 완전히 다른 것입니다. 위에서 언급한 Cloudflare 사용은 프록시 및 최적화를 의미하며, 과거에 꽤 엉망인 문제를 일으킨 적이 있습니다. 하지만 Cloudflare의 DNS는 괜찮고, 오히려 좋습니다.
Discourse 설치 환경은 변경할 필요가 없습니다. HTTPS가 작동하고 있고, 현재 모든 것이 정상입니다. SSL이 작동하고 CloudFlare 템플릿이 활성화되어 있다면 건드리지 마세요.
문제가 이제 WordPress 쪽인 것 같습니다. WordPress는 어떻게 설치되어 있나요? 그냥 VPS인가요, 아니면 어떤 형태의 WordPress 호스팅을 사용하고 있나요?
이것은 매우 일반적인 구성이며, 쉽게 해결될 것이라고 꽤 확신합니다.
이것은 매우 나쁜 아이디어입니다. Discourse가 Let’s Encrypt에서 인증서를 등록한 후에는 다른 메커니즘을 통해 갱신이 이루어지므로 갱신이 성공합니다. 서버와 CDN 사이의 TLS를 비활성화할 필요가 없습니다.
위 내용을 고려할 때 왜 이렇게 하겠습니까? 모든 트래픽에 대해 UFW 규칙을 처리하는 것만으로 추가적인 로컬 부하를 발생시킬 뿐만 아니라, 규칙이 최신 상태를 벗어나면 수많은 네트워크 오류가 발생하는 위험을 감수하게 됩니다. Cloudflare는 주기적으로 새로운 IP 범위를 도입하는데, 이것이 알려지기 전에 사용자가 사이트에 접근할 수 없게 되는 상황을 먼저 겪게 될 것입니다. 인증서 등록을 허용하고, CloudFlare를 사용하고자 한다면 단순히 페이지 규칙을 그에 맞게 조정하면 됩니다.
저는 Cloudflare를 DNS-only 모드로 사용하고 있어요. 아주 간단해요. DNS 관리 패널에서 주황색 구름 아이콘을 클릭해서 꺼주면 구름이 회색으로 바뀌어요. 이걸로 충분합니다.
이전처럼 더 이상 작동하지 않습니다. Let’s Encrypt를 원하지 않는 경우, discourse-setup 대신 수동으로 설정해야 합니다.
LE 이메일이 없는 경우 discourse에는 어떤 인증서가 발급될까요? 자체 생성된 인증서가 되나요, 아니면 임의의 이메일로 발급된 인증서가 되나요?
어떤 경우든, Cloudflare SSL은 유효한 인증서를 가진 호스트를 full SSL 설정 이상에서 허용하므로, 여전히 정상적으로 작동할 것입니다.
정확히 기억이 나지 않아 소스 코드를 확인해 보셔야 할 것 같습니다. 관리자 이메일을 사용한다고 생각합니다. 443 포트에서 서버가 사용 가능한지 확인하는 단계가 실패하면 설치를 거부합니다.
제가 완전히 틀렸을 수도 있지만, 이 코드
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER to skip"
else
local letsencrypt_status="Enter 'OFF' to disable."
fi
을 보면, 기본 설정 확인 시 "off"를 입력하여 letsencrypt를 비활성화할 수 있는 옵션이 제공되어야 하는 것 같습니다. 혹시 제가 완전히 틀렸거나 전혀 엉뚱한 곳을 보고 있는 건가요?
Let’s Encrypt를 비활성화하는 것은 해결책이 아닙니다.
표준 설치에서는 그렇지 않습니다.
고급 설치(예: 리버스 프록시를 사용하는 경우)에서는 완전히 적절한 답변입니다.
구체적인 이유를 설명해 주시겠어요?
인증서 시나리오를 작동하게 만드는 것은 쉽습니다. 같은 서버에서 두 번째 웹 서버를 운영하더라도 로컬로 프록시를 설정하면 인증서를 쉽게 작동시킬 수 있으므로, 왜 그렇게 하지 않는 건가요?
왜 여러 개의 인증서를 요청해야 합니까?
리버스 프록시(예: nginx/caddy)를 통해 Let’s Encrypt에서 하나의 통합 인증서를 요청할 수 있는데, 왜 아무것도 사용하지 않을 두 번째 인증서를 discourse 컨테이너 내부에서 요청하고 싶다는 것입니까?
개인적으로는 가능할 경우 프록시 관련 복잡성을 완전히 피하는 것이 일반적이라고 생각합니다 
하지만 표준적인 1~2개 컨테이너 구성을 넘어 배포를 살펴보기 시작하면 이를 피할 수 없습니다.
포럼이 Cloudflare의 프록시와 같은 기능이 필요할 정도로 상당히 커져야 합니다. 포럼이 과부하 상태에 빠지기 시작할 때 고려해 볼 수 있는 사항입니다. 대규모 포럼을 Discourse로 이전하는 경우가 아니라면, Discourse를 설치하는 사용자는 이 부분에 대해 생각할 필요가 없습니다.
솔직히 동의하지 않습니다. HTTPS를 올바르게 설정하는 것은 간단한 일입니다. 이 경우 사용자는 단일 도메인 아래에 서로 다른 두 서버에 두 개의 사이트를 보유하고 있습니다.
CloudFlare가 활성화되었든 아니든, 두 사이트 모두 HTTPS로 제공될 수 없는 기술적인 이유는 없습니다. Let’s Encrypt에서 사용하는 등록 방식을 이해하고 Discourse에 맞게 CloudFlare를 조정하는 방법을 알면 쉽게 수행할 수 있습니다. CloudFlare에는 정밀 HTTPS(Full HTTPS) 모드가 있으며, 이는 정확히 이러한 시나리오를 위해 존재합니다. 서버에서 CloudFlare 네트워크로, 그리고 네트워크에서 클라이언트로 각각 TLS가 적용되며, 중간에서 복호화되어 캐싱과 '최적화’가 가능합니다. 다만 Discourse의 경우 마지막 부분(최적화)이 잘 작동하지 않는다는 점은 알고 있습니다.
대부분 이 이유 때문이지만, /uploads/ 경로에 페이지 규칙 기반 캐싱을 적용하는 것이 확실히 이점이 있습니다. 일시적으로 부하를 줄여주고 저사양 VPS의 수명을 조금 더 연장하는 데 도움이 될 것입니다.