NGINX 프록시 설정
모든 플랜 에서 사용 가능
self-hosted 배포판
NGINX 서버 설치
NGINX는 인터넷 상에서 가장 크고 높은 트래픽을 가진 사이트들을 호스팅하는 역할을 맡은 인기 있는 웹 서버입니다. 대부분의 경우에 Apache보다 자원을 효율적으로 활용하며, 웹 서버 또는 리버스 프록시로 사용할 수 있습니다.
운영 환경에서는 Mattermost의 보안과 성능을 더욱 강화하기 위해 프록시 서버를 사용하는 것을 권장합니다.
SSL 종료
HTTP에서 HTTPS로 리디렉션
포트 매핑
:80에서:8065로표준 요청 로그
Ubuntu 서버에 NGINX 설치
프록시 호스트가 될 서버에 로그인하고 터미널 창을 엽니다.
NGINX를 설치합니다.
NGINX는 Ubuntu의 기본 저장소에서 이용 가능하기 때문에
apt패키지 시스템을 사용하여 이 저장소에서 설치할 수 있습니다. 먼저, 최신 패키지 목록에 액세스하기 위해 로컬apt패키지 색인을 업데이트합니다. 그런 다음,nginx를 설치합니다:
sudo apt update
sudo apt install nginx절차를 수락한 후,
apt는 NGINX와 서버에 필요한 의존성을 모두 설치할 것입니다.
설치를 완료한 뒤에는 이미 필요한 것 모두가 설치되어 있습니다. 브라우저를 서버 IP 주소로 지정하여 엽니다. 기본 NGINX 랜딩 페이지가 표시되어야 합니다:
이 페이지가 보인다면, 웹 서버에 NGINX가 성공적으로 설치된 것입니다. 이 페이지는 NGINX와 함께 제공되어 서버가 올바르게 실행 중인지 보여주는 역할을 합니다.
또는
curl http://localhost명령을 실행하여 확인할 수도 있습니다.만약 NGINX가 실행 중이라면, 다음 출력이 표시됩니다:
<!DOCTYPE html> <html> <head> <title>Welcome to nginx! </title> . . . *Thank you for using nginx.* </body> </html>
NGINX 프로세스 관리
이제 웹 서버가 실행 중이므로 몇 가지 기본 관리 명령을 확인해봅시다. 이러한 명령은 모두 명령 줄 인터페이스에서 실행됩니다.
웹 서버를 중지하려면 다음을 사용하세요: sudo systemctl stop nginx
중지된 웹 서버를 시작하려면 다음을 사용하세요: sudo systemctl start nginx
서비스를 중지한 다음 다시 시작하려면 다음을 사용하세요: sudo systemctl art nginx
구성 변경을 수행 중인 경우에는, 연결을 끊지 않고도 NGINX를 다시로드하는 경우가 많습니다. 이를 위해서는 다음을 사용하세요: sudo systemctl reload nginx
기본적으로 NGINX는 서버 부팅 시 자동으로 시작하도록 구성되어 있습니다. 이를 원하지 않는 경우, 다음을 사용하여 이 동작을 비활성화할 수 있습니다: sudo systemctl disable nginx
부팅 시 서비스를 다시 활성화하려면, 다음을 사용하세요: sudo systemctl enable nginx
다음 작업
mattermost.example.com과 같은 완전히 정규화된 도메인 이름(FQDN)을 DNS 서버/서비스에 매핑하여 NGINX 서버를 가리킵니다.인터넷에서 Mattermost 서버로의 프록시 연결을 구성합니다.
Mattermost 서버를 프록시로 구성하려면 NGINX 구성
NGINX는 /etc/nginx/sites-available 디렉터리에 있는 파일을 사용하여 구성됩니다. 파일을 생성한 다음 활성화해야 합니다. 파일을 생성할 때 Mattermost 서버의 IP 주소와 Mattermost 웹 사이트의 완전히 정규화된 도메인 이름(FQDN)이 필요합니다.
NGINX를 호스트하는 서버에 로그인하고 터미널 창을 엽니다.
Ubuntu에서는 다음 명령을 실행하여 Mattermost를 위한 구성 파일을 만듭니다.
sudo touch /etc/nginx/sites-available/mattermost
RHEL 8에서는 다음 명령을 실행하여 Mattermost를 위한 구성 파일을 만듭니다.
sudo touch /etc/nginx/conf.d/mattermost
텍스트 편집기에서
/etc/nginx/sites-available/mattermost(Ubuntu) 또는/etc/nginx/conf.d/mattermost(RHEL 8) 파일을 루트 사용자로 열고, 다음 줄로 파일의 내용(있는 경우)을 대체합니다. *server_name*에 자체 값 사용 여부를 확인하세요.
제공된 구성 예제에서 SSL 및 HTTP/2 및 서버 푸시가 활성화되어 있습니다.
Note
SSL 인증서를 관리하기 위해 Let’s Encrypt를 사용할 예정인 경우 SSL 구성 단계 3에서 중지하고 NGINX HTTP/2 및 SSL 제품 설명서 를 참조하세요.
NGINX가 SSL 인증서를 올바르게 매핑하려면 유효한 SSL 인증서가 필요합니다. 추가로 브라우저가 해당 인증서를 유효한 CA 인증서로 수락할 수 있는 권한이 있어야 합니다.
이 설명서의 예제에 포함된 IP 주소가 네트워크 구성과 일치하지 않을 수 있음을 참고하세요.
NGINX를 Mattermost와 같은 기계에서 실행하고 NGINX가
localhost를 두 개 이상의 IP 주소(IPv4 또는 IPv6)로 해석하는 경우,localhost대신127.0.0.1을 사용하는 것을 권장합니다.upstream backend { server 10.10.10.2:8065; keepalive 32; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off; server { listen 80 default_server; server_name mattermost.example.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name mattermost.example.com; http2_push_preload on; # HTTP/2 Server Push 활성화 ssl on; ssl_certificate /etc/letsencrypt/live/{domain-name}/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/{domain-name}/privkey.pem; ssl_session_timeout 1d; # TLS 버전 활성화(TLSv1.3은 곧 등장하는 HTTP/3 QUIC에 필요합니다). ssl_protocols TLSv1.2 TLSv1.3; # TLSv1.3의 0-RTT 활성화. 재생 공격을 방지하기 위해 역방향 프록시하는 경우 $ssl_early_data 사용. # # @see: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data ssl_early_data on; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384'; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:50m; # HSTS(ngx_http_headers_module이 필요함)(15768000초 = 6개월) add_header Strict-Transport-Security max-age=15768000; # OCSP 스테이플링 --- # ssl_certificate의 URL에서 OCSP 레코드를 가져와 캐시 ssl_stapling on; ssl_stapling_verify on; add_header X-Early-Data $tls1_3_early_data; location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; client_body_timeout 60; send_timeout 300; lingering_timeout 5; proxy_connect_timeout 90; proxy_send_timeout 300; proxy_read_timeout 90s; proxy_http_version 1.1; proxy_pass http://backend; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_http_version 1.1; proxy_pass http://backend; } } # TLS v1.3를 디버깅하는 데 유용한 이 블록은 자유롭게 제거하고 직접 NGINX에서 노출되는 `$ssl_early_data` 변수를 사용할 수 있습니다. map $ssl_early_data $tls1_3_early_data { "~." $ssl_early_data; default ""; }
기존의 default sites-enabled 파일을 삭제하려면 Ubuntu에서
sudo rm /etc/nginx/sites-enabled/default또는 RHEL 8에서sudo rm /etc/nginx/conf.d/default를 실행합니다.Mattermost 구성을 활성화하려면 Ubuntu에서
sudo ln -s /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost또는 RHEL 8에서sudo ln -s /etc/nginx/conf.d/mattermost /etc/nginx/conf.d/default.conf를 실행합니다.sudo systemctl art nginx를 실행하여 NGINX를 다시 시작합니다.curl https://localhost를 실행하여 프록시를 통해 Mattermost를 볼 수 있는지 확인하세요.
모든 것이 작동한다면, Mattermost 가입 페이지의 HTML이 표시됩니다.
포트 8065에 대한 액세스 제한.
기본적으로 Mattermost 서버는 네트워크의 모든 기계에서 포트 8065로 연결을 허용합니다. NGINX를 호스트하는 기계와 Mattermost 서버를 관리하는 기계를 제외한 모든 기계에서 포트 8065로의 연결을 방화벽을 사용하여 거부하세요. Amazon Web Services에 설치하는 경우 보안 그룹을 사용하여 액세스를 제한할 수 있습니다.
이제 NGINX가 설치되고 실행 중이므로 SSL을 사용하도록 구성하여 HTTPS 연결 및 HTTP/2 프로토콜을 사용할 수 있습니다.
NGINX를 SSL 및 HTTP/2로 구성
NGINX는 /etc/nginx/sites-available 디렉터리에 있는 파일을 사용하여 구성됩니다. 파일을 만들고 활성화해야 합니다. 파일을 만들 때 Mattermost 서버의 IP 주소와 Mattermost 웹사이트의 완전한 도메인 이름(FQDN)이 필요합니다.
SSL을 사용하면 Mattermost 클라이언트와 Mattermost 서버 간의 통신이 암호화되어 보안이 강화됩니다. 또한 NGINX를 HTTP/2 프로토콜을 사용하도록 구성할 수 있습니다.
SSL 없이도 HTTP/2를 구성할 수 있지만, Firefox와 Chrome 브라우저는 안전한 연결에서만 HTTP/2를 지원합니다.
원하는 인증서를 사용할 수 있지만, 이 지침은 무료 인증 기관 Let’s Encrypt 에서 인증서를 다운로드하고 설치하는 방법을 안내합니다.
Note
Let’s Encrypt이 활성화된 경우에는 Forward80To443 “config.json” 설정을 true 로 설정하여 Let’s Encrypt 인증을 완료하기 위해 방화벽을 통해 포트 80을 전달해야 합니다. 자세한 내용은 Let’s Encrypt/Certbot documentation 을 참조하십시오.
NGINX를 호스팅하는 서버에 로그인하고 터미널 창을 엽니다.
텍스트 편집기로 Mattermost
nginx.conf파일을 *root*로 열고,upstream backend의{ip}주소를 Mattermost(예:127.0.0.1:8065)로,server_name을 Mattermost의 도메인으로 업데이트합니다.
Note
Ubuntu에서 이 파일은
/etc/nginx/sites-available/에 있습니다. 이 파일이 없는 경우sudo touch /etc/nginx/sites-available/mattermost를 실행합니다.CentOS/RHEL에서 이 파일은
/etc/nginx/conf.d/에 있습니다. 이 파일이 없는 경우sudo touch /etc/nginx/conf.d/mattermost를 실행합니다.이 설명서의 예제에 포함된 IP 주소가 네트워크 구성과 일치하지 않을 수 있습니다.
만약 NGINX를 Mattermost와 동일한 머신에서 실행하고 NGINX가
localhost를 하나 이상의 IP 주소 (IPv4 또는 IPv6)로 해석하는 경우,localhost대신에127.0.0.1을 사용하는 것을 권장합니다.upstream backend { server {ip}:8065; keepalive 32; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off; server { listen 80 default_server; server_name mattermost.example.com; location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; client_body_timeout 60; send_timeout 300; lingering_timeout 5; proxy_connect_timeout 90; proxy_send_timeout 300; proxy_read_timeout 90s; proxy_pass http://backend; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_http_version 1.1; proxy_pass http://backend; } }
기존의 기본 sites-enabled 파일을 제거하려면
sudo rm /etc/nginx/sites-enabled/default(Ubuntu) 또는sudo rm /etc/nginx/conf.d/default(RHEL 8)을 실행합니다.Mattermost 구성을 활성화하려면
sudo ln -s /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost(Ubuntu) 또는sudo ln -s /etc/nginx/conf.d/mattermost /etc/nginx/conf.d/default.conf(RHEL 8)을 실행합니다.구성이 올바르게 완료되었는지 확인하려면
sudo nginx -t를 실행합니다. 오류가 발생하면 NGINX 구성을 검토하고/etc/nginx/sites-available/mattermost파일을 수정해야 합니다.sudo systemctl start nginx를 실행하여 NGINX를 다시 시작합니다.curl http://localhost를 실행하여 프록시를 통해 Mattermost를 확인합니다.
모든 것이 정상적으로 작동하면 Mattermost 가입 페이지의 HTML을 볼 수 있습니다. IP 또는 localhost로 액세스할 때 유효하지 않은 인증서가 표시됩니다. SSL 인증서가 올바르게 고정되었고 유효한지 확인하려면 완전한 FQDN 도메인을 사용하십시오.
sudo snap install core; sudo snap refresh core를 실행하여 Snap을 설치하고 업데이트합니다.sudo snap install --classic certbot을 실행하여 Certbot 패키지를 설치합니다.Certbot이 실행될 수 있도록 심볼릭 링크를 추가하려면
sudo ln -s /snap/bin/certbot /usr/bin/certbot을 실행합니다.DNS가 올바르게 구성되었는지 Dry-run을 실행하여 Let’s Encrypt 설치기가 정상적으로 실행되는지 확인하려면
sudo certbot certonly --dry-run을 실행합니다.
이 작업은 이메일 주소를 입력하고 TOS를 수락하고 이메일을 공유하며 certbot을 활성화하는 도메인을 선택하라는 메시지가 표시됩니다. 이를 통해 DNS가 이 서버를 올바르게 가리키고 인증서를 성공적으로 생성할 수 있는지 확인합니다. 이 작업이 성공하면 단계 12로 진행하십시오.
sudo certbot을 실행하여 Let’s Encrypt 설치기를 실행합니다. 이 작업은 certbot을 실행하고 선택한 사이트의 NGINX 구성 파일을 자동으로 수정합니다.SSL이 올바르게 구성되었는지 확인하려면
curl https://{your domain here}을 실행합니다.마지막으로, SSL 보안 설정을 기본 Let’s Encrypt 이상으로 수정하도록 config 파일을 편집하는 것을 권장합니다. 이는 위의 단계 2에서 사용한 파일과 동일합니다.
upstream backend { server {ip}:8065; keepalive 32; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off; server { server_name mattermost.example.com; location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; client_body_timeout 60; send_timeout 300; lingering_timeout 5; proxy_connect_timeout 90; proxy_send_timeout 300; proxy_read_timeout 90s; proxy_http_version 1.1; proxy_pass http://backend; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_http_version 1.1; proxy_pass http://backend; } listen 443 ssl http2; # managed by Certbot ssl_certificate /etc/letsencrypt/live/mattermost.example.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/mattermost.example.com/privkey.pem; # managed by Certbot # include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot ssl_session_timeout 1d; # Enable TLS versions (TLSv1.3 is required upcoming HTTP/3 QUIC). ssl_protocols TLSv1.2 TLSv1.3; # Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to # prevent replay attacks. # # @see: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data ssl_early_data on; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:50m; # HSTS (ngx_http_headers_module is required) (15768000 seconds = six months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; } server { if ($host = mattermost.example.com) { return 301 https://$host$request_uri; } # managed by Certbot listen 80 default_server; server_name mattermost.example.com; return 404; # managed by Certbot }
SSL 인증서가 올바르게 설정되었는지 확인하세요.
SSL 인증서를 https://www.ssllabs.com/ssltest/index.html 와 같은 사이트를 방문하여 테스트하세요.
빈 곳이나 인증서 경로에 대한 오류가 있는 경우 중간 인증서가 누락된 것으로 포함해야 합니다.
NGINX 구성 FAQ
웹소켓 연결이 403 오류를 반환하는 이유는 무엇인가요?
이는 크로스-오리진 검사에 실패한 것으로 보입니다. 웹소켓 코드에서 Origin 헤더가 호스트 헤더와 동일한지 확인하는 검사가 적용됩니다. 동일하지 않은 경우 403 오류가 반환됩니다. 루트로 텍스트 편집기에서 /etc/nginx/sites-available/mattermost 파일을 열고 프록시에서 설정되는 호스트 헤더가 동적인지 확인하세요.
location ~ /api/v[0-9]+/(users/)?websocket$ {
proxy_pass http://backend;
(...)
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
그런 다음 config.json 에서 AllowCorsFrom 설정을 클라이언트가 사용하는 도메인과 일치하도록 설정하세요. 클라이언트가 보낼 수있는 호스트 이름의 변형을 추가해야 할 수도 있습니다. 문제를 진단하는 데 NGINX 로그가 도움이 될 것입니다.
"EnableUserAccessTokens": false,
"AllowCorsFrom": "domain.com domain.com:443 im.domain.com",
"SessionLengthWebInDays": 30,
웹소켓 오류에 대한 기타 문제 해결 팁은 여기에서 확인하세요 .
Mattermost Docker 설치를 사용한 NGINX 프록시를 어떻게 설정하나요?
Mattermost 네트워크의 이름을 찾고 NGINX 프록시에 연결합니다.
docker network ls
# "mymattermost_default"와 같은 Mattermost 네트워크의 이름을 찾습니다.
docker network connect mymattermost_default nginx-proxy
Mattermost Docker 컨테이너를 다시 시작합니다.
docker-compose stop app
docker-compose start app
Tip
NGINX 프록시가 들어오는 요청을 허용하기 때문에 ‘web’ 컨테이너를 실행할 필요가 없습니다.
docker-compose.yml파일을 업데이트하여VIRTUAL_HOST와expose지시문을 추가하세요.
environment:
# db 자격 증명 및 데이터베이스 이름과 동일하게 설정
- MM_USERNAME=mmuser
- MM_PASSWORD=mmuser-password
- MM_DBNAME=mattermost
- VIRTUAL_HOST=mymattermost.tld
expose:
- "80"
- "443"
Azure에서 Gitlab CE와 Mattermost를 함께 설치할 때 NGINX가 실패하는 이유는 무엇인가요?
Mattermost의 응용 프로그램 항목의 콜백 URL을 업데이트해야 할 수 있습니다.
관리자로서 GitLab 인스턴스에 로그인합니다.
Admin > Applications 으로 이동합니다.
GitLab-Mattermost에서 편집 을 선택합니다.
새 도메인/URL로 콜백 URL을 업데이트합니다.
변경사항을 저장합니다.
/etc/gitlab/gitlab.rb구성 파일에서 GitLab 및 Mattermost의 외부 URL을 업데이트합니다.
Certbot가 http-01 도전에 실패하는 이유는 무엇인가요?
yourdomain.com에 대한 인증서를 요청 중
다음 도전 수행 중:
yourdomain.com에 대한 http-01 도전
확인을 기다리는 중...
도메인 yourdomain.com에 대한 도전 실패
yourdomain.com에 대한 http-01 도전
도전 정리 중
일부 도전에 실패했습니다.
위의 오류가 표시된다면 대개 Certbot이 포트 80에 액세스할 수 없었기 때문입니다. 이는 방화벽 또는 다른 DNS 구성으로 인할 수 있습니다. A/AAAA 레코드가이 서버를 가리키도록하고 NGINX 구성 내의 server_name 이 리디렉션되지 않았는지 확인하십시오.
Note
Cloudflare을 사용하는 경우 force traffic to https 를 해제해야 합니다.
Certbot 속도 제한
만약 독립적으로 certbot을 실행 중이라면 다음과 같은 오류가 표시됩니다:
example.com에 대한 Let's Encrypt SSL/TLS 인증서를 발급할 수 없습니다.
example.com에 대해 Let's Encrypt 속도 제한 중 하나가 초과되었습니다.
자세한 내용은 관련 지식 베이스 문서를 참조하십시오.
세부 정보
https://acme-v02.api.letsencrypt.org/acme/new-order에서 유효하지 않은 응답입니다.
세부 정보:
유형: urn:ietf:params:acme:error:rateLimited
상태: 429
자세한 내용: 새 주문 생성 오류 :: 최근에 실패한 인증이 너무 많습니다: https://letsencrypt.org/docs/rate-limits/
만약 Mattermost 내에서 Let’s Encrypt를 실행 중이라면 다음과 같은 오류가 표시됩니다:
{"level":"error","ts":1609092001.752515,"caller":"http/server.go:3088","msg":"http: TLS handshake error from ip:port: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/","source":"httpserver"}
이는 인증서를 생성하려는 시도가 너무 많았음을 의미합니다. 자세한 내용은 여기 에서 찾을 수 있습니다.
