# 요청 설정 (/ko/docs/requests/settings)

<strong>설정</strong> 탭은 요청이 오가는 방식을 정합니다. 어떤 HTTP 버전을 쓸지, 리디렉션을 따를지, 쿠키를 유지할지, 인증서를 확인할지, 얼마나 오래 걸려도 되는지입니다. 프록시와
인증서는 이 페이지 아래쪽에서 작업 공간 전체 또는 앱 전체에 대해 설정합니다.

<Shot id="requests-http-settings" alt="요청의 설정 탭: 원본 모드, 설명이 붙은 자동 HTTP 버전, TLS 인증서 확인, 최대 리디렉션 횟수 10인 리디렉션 따르기, 쿠키, 응답 압축 해제, 시간 초과 60 s" />

## 설정 탭 [#the-settings-tab]

| 설정 | 기본값 | 동작 |
| --- | --- | --- |
| <strong>원본 모드</strong> | 꺼짐 | <strong>헤더</strong> 탭의 헤더를 아무것도 추가하지 않고 그대로 보냅니다. |
| <strong>HTTP 버전</strong> | <strong>자동</strong> | <strong>자동</strong>, <strong>HTTP/1.1</strong>, <strong>HTTP/2</strong>, <strong>HTTP/3</strong> 중에서 선택합니다. |
| <strong>TLS 인증서 확인</strong> | 켜짐 | `https://` 주소에서 서버의 인증서를 확인합니다. |
| <strong>리디렉션 따르기</strong> | 켜짐 | <strong>최대 리디렉션 횟수</strong>까지 3xx 응답을 따라갑니다. |
| <strong>최대 리디렉션 횟수</strong> | 10 | 1에서 50까지. |
| <strong>쿠키 보내기 및 저장</strong> | 켜짐 | 윈도우의 쿠키 저장소에 있는 해당 주소의 쿠키를 보내고, 응답이 설정하는 쿠키를 보관합니다. |
| <strong>응답 압축 해제</strong> | 켜짐 | 압축된 응답을 요청하고 디코딩합니다. |
| <strong>시간 초과</strong> | 60 s | 교환 전체에 허용되는 시간. 1초에서 1시간까지 5초 단위. |

변경한 설정만 요청 파일에 저장됩니다. 기본값과 다른 설정이 있으면 탭에 점이 표시되고, 원본 모드가 켜져 있는 동안은 <strong>설정(원본)</strong>이라고 표시됩니다.
<strong>기본값으로 재설정</strong>은 모든 설정을 되돌립니다.

요청 파일에서는 설정이 다음과 같이 보입니다.

```toml
[settings]
http-version = "http2"
follow-redirects = false
timeout = 10.0
```

## HTTP 버전 [#http-version]

| 선택 | Echolot이 사용하는 것 |
| --- | --- |
| <strong>자동</strong> | 서버가 제공하면 HTTP/2, 아니면 HTTP/1.1. 서버가 (`Alt-Svc` 헤더로) HTTP/3을 제공하면 이후 해당 서버로 보내는 요청은 HTTP/3을 사용하며, 연결되지 않으면 TCP로 대체합니다. |
| <strong>HTTP/1.1</strong> | HTTP/1.1만. |
| <strong>HTTP/2</strong> | HTTP/2만. TLS를 통해서, 또는 사전 지식(h2c)을 이용한 일반 `http://`로. |
| <strong>HTTP/3</strong> | QUIC 기반 HTTP/3만. |

HTTP/3에는 제한이 있습니다.

- <strong>macOS 27 이상</strong>이 필요합니다. 이전 Mac에서는 탭에 그렇게 표시되고 <strong>HTTP/3</strong>으로 설정한 요청은 보낼 수 없으며, <strong>자동</strong>은 HTTP/2와 HTTP/1.1을 유지합니다.
- `https://` 주소만 가능합니다.
- 프록시(시스템 프록시 포함)를 쓸 수 없고, 사용자 지정 CA 파일과 클라이언트 인증서도 쓸 수 없습니다. <strong>HTTP/3</strong>으로 설정한 요청에 이 중 하나가 필요하면 이유와 함께
  거부됩니다. <strong>자동</strong>에서는 그런 요청이 TCP를 유지합니다.
- 원본 모드는 HTTP/3과 함께 쓸 수 없습니다.

<strong>자동</strong>에서 응답이 HTTP/3을 제공하면 세부 정보 카드에 <strong>HTTP/3 제공됨</strong>이 표시됩니다. 다음 요청의 QUIC 연결이 실패하면 Echolot은 대신 TCP로 보내고, 제공된 내용을
잊으며, 세부 정보 카드에 이유가 표시됩니다. 두 번 보내지는 일은 없습니다.

두 가지 경우에는 버전이 저절로 바뀝니다.

- [NTLM](/docs/requests/auth#ntlm)은 HTTP/1.1이 필요합니다. <strong>자동</strong>에서는 NTLM 요청이 HTTP/1.1로 가고, <strong>HTTP/2</strong>나 <strong>HTTP/3</strong>에서는 거부됩니다.
- 서버가 HTTP/2 요청을 `HTTP_1_1_REQUIRED`로 재설정하면 Echolot은 그 뒤로 그 서버와 HTTP/1.1로 통신합니다. 반복해도 안전한 요청은 바로 HTTP/1.1로 다시 보내고,
  다른 요청은 그렇다는 오류와 함께 중단되며 다시 보내면 HTTP/1.1로 나갑니다.

응답의 세부 정보 카드에는 사용된 버전이 TLS 버전 옆에 표시됩니다.

## 리디렉션 [#redirects]

<strong>리디렉션 따르기</strong>를 켜면 Echolot은 `http://`와 `https://` 주소로 가는 `301`, `302`, `303`, `307`, `308` 응답을 따라갑니다.

- `303`은 본문 없는 `GET`이 됩니다(`HEAD`는 `HEAD`로 유지).
- `301`과 `302`는 브라우저처럼 `POST`를 `GET`으로 바꿉니다.
- `307`과 `308`은 메서드와 본문을 유지합니다.

모든 홉이 기록됩니다. 세부 정보 카드에 <strong>리디렉션 3회</strong>(또는 해당 횟수)가 표시되며, 클릭하면 각 홉의 상태, 메서드, 주소, 시간과 최종 주소를 볼 수 있습니다. Alpenglow의
<strong>Echo › Follow redirects</strong>로 시험해 보십시오.

다른 출처로의 리디렉션에서는 자격 증명이 제거됩니다. `Authorization`과 `Cookie` 헤더, API 키 헤더, 비밀 값이 들어 있는 헤더, 서명(Digest, AWS, Hawk, EdgeGrid,
NTLM), 클라이언트 인증서입니다. [자격 증명은 출처에 머뭅니다](/docs/requests/auth#credentials-stay-with-their-origin)를 참고하십시오.

<strong>리디렉션 따르기</strong>가 꺼져 있으면 3xx 응답이 곧 응답입니다.

## 쿠키 [#cookies]

윈도우마다 쿠키 저장소가 있습니다. <strong>쿠키 보내기 및 저장</strong>을 켜면 요청은 저장소에서 자신의 주소와 일치하는 쿠키를 보내고, 응답이 설정하는 쿠키는 저장소에 들어갑니다.
어떤 쿠키도 보내거나 보관하지 않아야 하는 요청에서는 끕니다.

응답의 <strong>쿠키</strong> 탭에는 <strong>요청과 함께 보냄</strong>, <strong>응답이 설정함</strong>, <strong>이 윈도우에 저장됨</strong>이 표시됩니다. 쿠키 하나는 해당 버튼으로, 전체는 <strong>모두 지우기</strong>로 제거합니다.
[응답](/docs/requests/responses#cookies)을 참고하십시오.

저장소는 브라우저의 규칙을 따릅니다. 응답은 `.com`이나 `.co.uk` 같은 공개 접미사 전체에 대해서는 쿠키를 설정할 수 없습니다. Alpenglow의 <strong>Echo › Set a cookie</strong>를
시험한 다음 `demo.echolot.dev`로 가는 다른 요청을 보내 보십시오.

## 응답 압축 해제 [#decompress-responses]

<strong>응답 압축 해제</strong>를 켜면 Echolot은 (해당 헤더를 직접 설정하지 않았다면) `Accept-Encoding: gzip, deflate, br, zstd`를 보내고 gzip, deflate, Brotli, Zstandard
응답을 디코딩합니다. <strong>본문</strong> 탭에는 디코딩된 본문이 표시되고, 도착한 그대로의 바이트는 <strong>통신</strong> 탭에 남으며, 본문의 저장 메뉴에서 <strong>인코딩된 본문 저장…</strong>을 쓸 수 있습니다.
세부 정보 카드에는 예를 들어 `br, 12 KB → 48 KB`처럼 표시됩니다.

서버가 압축한 그대로 응답을 보거나 `Accept-Encoding` 헤더를 보내지 않으려면 끕니다.

## TLS 인증서 확인 [#verify-tls-certificates]

서버의 인증서를 Mac이 신뢰하지 않는데 그 CA를 추가할 수도 없는 서버를 시험하는 경우가 아니면 켜 두십시오. 끄면 세부 정보 카드에 주황색의 열린 자물쇠가 표시되고 팝오버에
<strong>인증서 확인 꺼짐</strong>이라고 나옵니다.

사설 CA에는 해당 호스트에 대해 그 CA를 신뢰하는 편이 더 낫습니다. [인증서](#certificates)를 참고하십시오.

## 시간 초과 [#timeout]

시간 초과는 연결부터 마지막 바이트까지 교환 전체에 허용되는 시간입니다. 시간이 다 되면 요청이 <strong>요청 시간이 초과되었습니다</strong>와 함께 중단되고 연결이 닫힙니다.

## 원본 모드 [#raw-mode]

원본 모드는 잘못된 형식의 요청까지 포함해, 서버가 어떻게 처리하는지 시험하기 위해 요청을 작성한 바이트 그대로 보내는 모드입니다. Echolot은 모든 요청에 추가하는 헤더(`Host`,
`User-Agent`, `Accept`, `Accept-Encoding`, `Cookie`, `Content-Length`와 프레이밍)를 넣지 않으며 요청의 형식이 올바른지도 검사하지 않습니다. <strong>헤더</strong> 탭의
<strong>자동 생성</strong> 아래에 <strong>원본 모드: Echolot은 헤더를 추가하지 않으며 위에 있는 헤더만 보냅니다.</strong>라고 표시됩니다.

직접 쓴 헤더만 보내는 요청을 만들려면 <strong>인증</strong>도 <strong>인증 없음</strong>으로 설정하고, 본문에 필요하면 직접 `Content-Type`을 쓰십시오. 원본 모드는 HTTP/1.1로 쓰기 때문에
HTTP/3과 함께 쓸 수 없습니다.

## 재시도 [#retries]

Echolot은 연결을 열어 둔 채 재사용하여 DNS, 연결, TLS 시간을 아낍니다. 재사용하면 세부 정보 카드에 <strong>재사용된 연결</strong>이 표시됩니다. 때로는 서버가 열어 둔 연결을 요청이 나가는
바로 그 순간에 닫아 버립니다. 이때는 다음과 같이 합니다.

- 반복해도 안전한 요청은 새 연결로 다시 보냅니다. `GET`, `HEAD`, `OPTIONS`, `TRACE`, `PUT`, `DELETE`, 또는 `Idempotency-Key` 헤더가 있는 요청입니다.
  세부 정보 카드에 다시 보냈다고 표시됩니다.
- 그 밖의 요청(`Idempotency-Key`가 없는 `POST` 등)은 서버가 이미 처리했을 수 있으므로 다시 보내지 않습니다. **응답이 도착하기 전에 연결이 닫혔습니다. 서버가 요청을 이미
  처리했을 수 있습니다**라는 메시지와 함께 중단됩니다.

Echolot은 그 밖의 경우에는 재시도하지 않습니다.

## 프록시 [#proxies]

요청은 기본적으로 <strong>설정 › 네트워크</strong>에서 선택한 프록시를 거칩니다.

| 프록시 | 의미 |
| --- | --- |
| <strong>시스템 설정</strong> | <strong>시스템 설정 › 네트워크</strong>의 HTTP, HTTPS, SOCKS 프록시와 그 예외. 자동 프록시 구성(PAC)은 사용하지 않습니다. |
| <strong>없음</strong> | 모든 요청이 직접 연결됩니다. |
| <strong>수동</strong> | `http://proxy:3128`이나 `socks5://host:1080` 같은 HTTP, HTTPS(프록시까지 TLS), SOCKS5 프록시. 선택적으로 사용자 이름과 비밀번호(키체인에 보관)를 지정하며, <strong>직접 연결</strong>(`localhost, *.internal`)에 직접 도달할 호스트를 지정합니다. |

작업 공간은 자체 프록시를 설정할 수 있으며, 이 설정은 팀원과 명령줄 도구에도 함께 전달됩니다.

1. 사이드바 하단의 작업 공간 전환기에서 <strong>작업 공간 설정…</strong>을 엽니다.
2. <strong>프록시</strong> 탭을 선택하고 <strong>앱의 프록시 설정 사용</strong>을 끕니다.
3. <strong>시스템 설정</strong>, <strong>환경(HTTPS_PROXY…)</strong>(`HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY`를 읽음), <strong>없음</strong>, <strong>수동</strong> 중에서 선택합니다.
4. <strong>수동</strong>에서는 <strong>프록시</strong>(`{{proxy}}`처럼 변수를 쓸 수 있음), <strong>사용자 이름</strong>, <strong>비밀번호</strong>, <strong>직접 연결</strong>을 입력합니다. 비밀번호는 `{{proxy_password}}`처럼
   비밀 변수로 쓰십시오. 작업 공간 파일에는 비밀 값이 저장되지 않습니다. 비밀번호를 그대로 입력하면 <strong>키체인으로 이동</strong>이 제안됩니다.

HTTP/3은 프록시를 거치지 않습니다. [작업 공간](/docs/workspaces)을 참고하십시오.

## 인증서 [#certificates]

사설 인증 기관을 쓰거나 클라이언트 인증서(상호 TLS)를 요구하는 호스트에는 작업 공간에 규칙을 추가합니다.

1. <strong>작업 공간 설정…</strong>을 열고 <strong>인증서</strong> 탭을 선택합니다.
2. <strong>호스트 추가</strong>를 클릭하고 `api.example.com`처럼 호스트를 입력하거나, 모든 하위 도메인에는 `*.internal`을 입력합니다.
3. <strong>신뢰할 CA</strong> 옆에서 <strong>선택…</strong>을 클릭하고 PEM 파일을 하나 이상 고릅니다. 시스템의 인증서에 더해 신뢰됩니다.
4. 클라이언트 인증서는 <strong>클라이언트 인증서</strong> 옆에서 파일을 선택합니다. PEM 파일 또는 `.p12`(`.pfx`)입니다. 키가 없는 PEM 인증서 파일에는 <strong>개인 키</strong> 파일도 선택합니다.
5. 키 또는 `.p12`에 암호가 있으면 <strong>암호</strong>에 `{{p12_passphrase}}`처럼 비밀 변수로 씁니다.

호스트와 일치하는 첫 번째 규칙이 적용됩니다. 작업 공간 안의 파일은 작업 공간 기준 상대 경로로 저장되므로 규칙이 작업 공간을 가진 모든 사람에게 동작합니다. 각 규칙의 인증서는 그
호스트에만 사용되며, 다른 호스트로의 리디렉션이 첫 호스트의 클라이언트 인증서를 제시하는 일은 없습니다.

<Edition only="appstore">
  App Store 버전은 사용자가 직접 선택한 파일만 읽을 수 있습니다. 여기서 선택한 CA 파일, 클라이언트 인증서, 키는 이후에 보낼 때도 계속 읽을 수 있습니다. 팀원이 만든
  규칙이 작업 공간 밖의 파일을 가리키면 그 파일을 앱에 한 번 허용해야 합니다. 보내기가 중단되고 응답 패널에 <strong>접근 허용…</strong>이 표시됩니다.
</Edition>

## 앱 전체 설정 [#app-wide-settings]

프록시는 앱 전체의 기본값이 있는 유일한 요청 설정입니다(<strong>설정 › 네트워크</strong>). 그 밖의 설정은 요청마다 위 표의 기본값에서 시작하며 요청 파일에 변경한 내용이 보관됩니다.
여러 요청의 설정을 한꺼번에 바꾸려면 사이드바에서 요청들을 선택하고 <strong>요청 N개 편집…</strong>으로 헤더, 매개변수, 인증을 바꾸거나 파일을 직접 편집하십시오.