アドレス

キューブとサンドボックスのリンクの公開アドレスには、それぞれ 2 つの形式があります。指定しなければ使われるプロキシ経由の形式は、前段のプロキシ（Cloudflare）を通ってプラットフォームに届きます。プロキシは TLS 接続を受け持ち、攻撃（DDoS）を吸収し、リクエストをフィルタリングし、応答をキャッシュできます。ダイレクトの形式は、間に何も挟まずにプラットフォーム自身のエッジに届き、プロキシが運べないもののために使います。

SSH は常にダイレクトです。

プロキシの制限

より大きなアップロード、何も送らずに長く続くリクエスト、HTTP 以外のプロトコルには、ダイレクトな名前を使います。あるいは、分割してアップロードする、すぐに 202 を返してクライアントに再度問い合わせさせる、長いレスポンスでは少なくとも 100 秒ごとに何かを送る、といった方法もあります。

キューブと独自ドメインのレスポンスは、その Cache-Control に従ってプロキシがキャッシュします。サンドボックスのリンクのレスポンスは、サンドボックス自身のレスポンスが Cloudflare-CDN-Cache-Control を設定しない限り、キャッシュされません。

ダイレクトな名前

• キューブは、direct: true（POST /v1/apps または PATCH /v1/apps/{app}）でダイレクトな名前を得ます。そのレスポンスには direct_url が含まれ、false で外せます。求めなかったアプリには、プロキシ経由のアドレスしかありません。
• サンドボックスのリンクには、常にダイレクトな形式があります。リンクの先頭部分を direct.glac.run の下に置くだけで、設定は不要です。
• ダイレクトな名前には、プロキシによる保護はありません。守るのはエッジ自身の制限だけで、1 つの訪問者のアドレスからの同時接続は最大 500（IPv6 の /64 は 1 つと数えます。超えると 429 too_many_connections）、1 つのサンドボックスやキューブへは 1,000、1 つのエッジへは 6,000 です。

独自ドメイン

{domain, app} を付けた POST /v1/domains は proxied も受け付け（指定しなければ true）、PATCH /v1/domains/{id} で変更できます。

• プロキシ経由：独自の名前から <token>.glac.run への CNAME を設定します。プロキシが名前を証明して証明書を発行し、更新も自動で行います。レスポンスの proxy が状況を示します。waiting、full（空き待ち）、pending（名前の証明と証明書の発行中）、active、またはプロキシ自身のメッセージを添えた failed です。proxy.records には、名前を向ける前に証明書を得るために追加できるレコードが挙げられます。
• ダイレクト：<token>.direct.glac.run への CNAME、またはレスポンスが示す A レコードと AAAA レコードを、TXT による証明とともに設定します。エッジが Let’s Encrypt から証明書を発行し、更新します。新しい名前の証明書、更新された証明書、削除された名前は、すべてのエッジで次の TLS ハンドシェイクから反映され、そのためにほかのものが再起動されることはありません。
• ドメインの頂点（Zone Apex）の名前（example.com）は、A レコードではプロキシ経由にできません。DNS がそこで CNAME をフラット化できる（ALIAS、ANAME）場合にだけプロキシ経由にし、そうでなければ proxied: false で登録してください。
• proxied を変えると、キューブへの経路が変わります。証明書は新しい経路のものになるため、ドメインは再び証明書の発行待ちになります。
• リクエストがプロキシを通るかどうかは DNS で決まります。ダイレクトな宛先に向けた名前は、ダイレクトで処理されます。