네트워크 디버깅

Chute는 프록시지만, 자기 기기에서 프록시를 돌리는 이유는 보통 경로 선택이 아닙니다. 이제 모든 요청이 내가 통제하는 곳을 지나간다는 것 — 그것이 이유입니다. 그래서 앱이 실제로 무엇을 보내는지 지켜볼 수 있고, 본문을 남겨 두었다가 나중에 읽을 수 있고, 전송 중인 요청이나 응답을 바꿀 수 있으며, 멀쩡한 백엔드를 고장 난 것처럼 보이게 만들어 앱이 어떻게 하는지 확인할 수 있습니다.

각 장치의 참조 페이지는 이 설명서의 다른 곳에 있습니다: HTTPS 복호화, 모의 응답, URL 재작성, JS 스크립팅. 이 절은 그것들을 실제로 쓰는 순서대로 놓고, 플랫폼마다 무엇이 달라지는지 말합니다.

같은 커널을 보는 네 개의 창

실행 중인 Chute는 하나, 보는 방법은 넷. 창을 잘못 고르는 것이 "거기에 없다"의 흔한 이유입니다.

콘솔과 Dashboard는 크게 겹치지만 들어가는 길이 다릅니다 — 콘솔은 커널이 제공하고 브라우저로 열며, Dashboard는 바이너리 채널로 말하는 Mac 애플리케이션입니다. 어느 쪽도 다른 쪽의 상위 집합이 아닙니다. 차이는 Dashboard가 닿지 못하는 것에 있습니다.

먼저 스위치 네 개를 맞추십시오

"연결은 보이는데 요청이 안 보인다"는 거의 언제나 이 넷 중 하나에서 끝납니다. 이 순서로 확인하십시오:

1. 트래픽이 애초에 Chute에 닿고 있다. 트래픽 보기에 행 하나가 있으면 그것이 증거입니다. 아무것도 없다면 디버깅 문제가 아니라 가로채기 문제입니다 — 문제 해결을 보십시오.
2. CA가 설치되어 있고 신뢰되고 있다. iOS에서는 두 단계, macOS에서는 한 단계, tvOS에서는 둘 다 앱 안에서 하지 않습니다 — CA 인증서 설치와 신뢰를 보십시오.
3. 호스트가 MitM 목록에 있다. Chute는 선언된 호스트만 복호화합니다. 메서드도 상태 코드도 없이 CONNECT라고 적힌 행은 한 번도 복호화된 적이 없습니다.
4. 기록이 켜져 있다. replica = true, 또는 스위치(Mac에서는 Traffic Capture, iOS와 tvOS에서는 데이터 덤프). 없어도 모든 행은 규칙·정책·타이밍을 가집니다 — 빠지는 것은 페이로드뿐입니다. [Replica]가 무엇을 남길지 다시 좁힙니다.

3번과 4번은 콘솔에서도, Dashboard에서도, API로도 실행 중에 바꿀 수 있지만, 어느 것도 설정 파일에 다시 쓰이지 않습니다. 재시작하면 파일이 이깁니다.

플랫폼별로 할 수 있는 것

여기서 어디로

• Mac에서 iPhone 디버깅하기 — 갓 꺼낸 휴대전화에서 Mac 화면의 복호화된 본문까지, 전 과정.
• Mac에서 디버깅하기 — Mac 자신의 트래픽. 터미널 도구와 프로세스 단위 분리를 포함합니다.
• Apple TV 디버깅하기 — 브라우저도 공유 시트도 없고, 스스로 인증서를 설치할 방법도 없는 기기.
• 복제 — 어떤 연결이 본문을 남기는지, 그리고 전부 캡처하는 것을 멈추는 법.
• 모의 응답과 장애 주입 — 정해진 응답, 오류 상태 코드, 지연 주입, 그리고 Chute가 정말로 할 수 없는 것.

질문이 "무엇을 하고 있나"가 아니라 "안 된다"라면 문제 해결에서 시작하십시오. 특히 내 재작성은 왜 아무것도 하지 않을까? — 이 절이 가장 자주 만들어 내는 질문이 그것입니다.