> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ko/self-hosted/enterprise/secure-gateway.md).

# Secure Gateway

Secure Gateway는 Roboflow Inference Server를 인터넷으로부터 방화벽으로 격리할 때 사용하는 Roboflow API 및 모델 가중치용 프록시입니다. 이는 다음의 후속 서비스입니다. [라이선스 서버](/deployment/ko/self-hosted/enterprise/license-server.md) 그리고 모델 가중치와 컨테이너 이미지의 로컬 캐싱을 추가하여, 추론 서버 플릿이 하나의 통제된 송신 지점을 공유하도록 합니다.

{% hint style="info" %}
이 페이지에서는 핵심 사항을 다룹니다. 전체 구성 및 운영 참조는 다음을 확인하세요. [Secure Gateway 매뉴얼](https://secure-gateway.roboflow.com/manual/).
{% endhint %}

## 사전 요구 사항

* Docker Engine 20.10 이상 또는 Kubernetes v1.24 이상
* api.roboflow\.com 및 repo.roboflow\.com에 액세스할 수 있는 호스트
* 포트 80 사용 가능, 게이트웨이 앞의 로드 밸런서 또는 컨테이너 내부에서 TLS 종료
* 4GB 이상 메모리
* S3 버킷 또는 캐시용 로컬 디스크 50GB 이상

{% hint style="info" %}
Red Hat Enterprise Linux에 배포하시나요? [Podman을 사용하는 RHEL의 Secure Gateway](/deployment/ko/self-hosted/enterprise/secure-gateway-podman.md) 에서는 Docker 또는 Kubernetes가 없는 RHEL 호스트를 다루며, [MicroShift의 Secure Gateway](/deployment/ko/self-hosted/enterprise/secure-gateway-microshift.md) 에서는 MicroShift를 실행하는 Red Hat Device Edge 호스트를 다룹니다. 둘 다 동일한 에어갭 번들 모델을 사용하는 전용 설치 관리자를 사용합니다.
{% endhint %}

## Secure Gateway 사용

다음에 액세스할 수 있는 머신에서 `https://api.roboflow.com` 및 `https://repo.roboflow.com` (그리고 포트 `80` 가 프라이빗 네트워크에서 실행 중인 Inference Server에 열려 있는 경우), Secure Gateway 컨테이너를 가져옵니다:

```
docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

\` `latest` 태그는 가장 최신 릴리스를 따릅니다. 프로덕션, 특히 에어갭 배포의 경우 업그레이드가 의도적이고 재현 가능하도록 대신 특정 버전을 고정하세요. 예: `repo.roboflow.com/roboflow-edge/secure-gateway:0.2.0`.

로컬 디스크 캐시를 사용하여 실행합니다:

```
docker run -d --name secure-gateway -p 80:80 --restart unless-stopped \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

실행 중인지 확인합니다:

```
curl http://localhost/health
```

로컬 디스크 대신 S3에 캐시하려면 다음을 설정하세요. `CACHE_S3_BUCKET` 및 `CACHE_S3_REGION` 환경 변수. 인스턴스 또는 IAM 역할을 사용하려면 자격 증명은 설정하지 마세요.

## TLS 인증서

기본적으로 게이트웨이는 일반 HTTP에서 수신 대기하며, 그 앞의 로드 밸런서에서 TLS를 종료합니다. 게이트웨이 자체에서 HTTPS를 제공하려면 인증서와 프라이빗 키를 컨테이너에 마운트하고 다음 둘 다 설정하세요. `TLS_CERT_FILE` 및 `TLS_KEY_FILE`. 그러면 게이트웨이는 구성된 포트에서 HTTPS를 제공합니다:

```
docker run -d --name secure-gateway -p 443:443 --restart unless-stopped \
    -e PORT=443 \
    -e TLS_CERT_FILE=/etc/ssl/certs/gateway.crt \
    -e TLS_KEY_FILE=/etc/ssl/private/gateway.key \
    -v /path/to/certs:/etc/ssl:ro \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest
```

둘 다 `TLS_CERT_FILE` 및 `TLS_KEY_FILE` 인바운드 HTTPS를 활성화하려면 필요하며, 각각 PEM 인코딩 파일을 가리킵니다.

게이트웨이의 아웃바운드 트래픽이 Zscaler와 같은 기업용 TLS 검사 프록시를 통과하는 경우 다음을 설정하세요. `TLS_CA_BUNDLE` 를 해당 프록시의 CA 번들로 설정하여 게이트웨이가 api.roboflow\.com 및 repo.roboflow\.com에 대한 연결을 신뢰하도록 합니다:

```
-e TLS_CA_BUNDLE=/etc/ssl/certs/corporate-ca.pem
```

## Inference Server 연결

각 Inference Server를 게이트웨이에 연결하려면 다음을 사용하세요. `SECURE_GATEWAY` 환경 변수. 스키마 없이 게이트웨이의 호스트 이름 또는 IP 주소로 설정합니다. 그러면 Inference Server는 인터넷에 직접 연결하는 대신 Roboflow API 호출과 모델 가중치 다운로드를 게이트웨이를 통해 라우팅합니다.

```
sudo docker run --net=host \
    --env SECURE_GATEWAY=10.0.1.1 \
    roboflow/inference-server:cpu
```

게이트웨이가 80 이외의 포트에서 수신 대기하는 경우 해당 포트를 포함하세요. 예: `SECURE_GATEWAY=10.0.1.1:8080`. 스키마가 없는 값은 다음으로 처리됩니다. `http://`, 따라서 Inference Server는 이 주소에서 HTTP를 통해 게이트웨이에 연결합니다. Inference Server의 네트워크에서 호스트와 포트에 연결할 수 있는지 확인하세요.

게이트웨이가 일반 HTTP 대신 HTTPS를 제공하는 경우, 다음 [Podman을 사용하는 RHEL](/deployment/ko/self-hosted/enterprise/secure-gateway-podman.md) 및 [MicroShift](/deployment/ko/self-hosted/enterprise/secure-gateway-microshift.md) 배포는 모두 그러하므로, 값에 스키마를 포함하고 (`SECURE_GATEWAY=https://gateway.example.com`) Inference Server가 게이트웨이의 인증서를 신뢰하는지 확인하세요.

api.roboflow\.com 및 repo.roboflow\.com에 대한 아웃바운드 액세스는 게이트웨이에만 필요합니다. Inference Server가 시작된 후 모델을 실행하고 요청이 게이트웨이의 액세스 로그에 표시되는지 확인하세요.

레거시 `LICENSE_SERVER` 변수는 여전히 다음의 별칭으로 허용됩니다. `SECURE_GATEWAY`, 따라서 기존 배포는 계속 작동합니다. 이는 더 이상 사용되지 않으며 2026년 3분기 말에 제거될 예정입니다.

## 캐싱

Secure Gateway는 첫 다운로드 시 각 응답을 캐시하며, 콘텐츠 변경 빈도에 따라 계층화합니다. 콘텐츠 주소 지정 컨테이너 블롭과 모델 가중치는 가장 오래 보관되고, 변경 가능한 API 응답은 더 짧은 기간 동안 보관됩니다. 모든 Inference Server의 후속 요청은 캐시에서 제공되므로 플릿 전체의 대역폭 사용량과 콜드 스타트가 줄어듭니다.