실제 기기에서의 모킹은 대부분의 구성이 무너지는 지점입니다. 스텁 서버는 노트북에 있고, 휴대폰은 거기에 닿아야 하며, 앱은 그쪽을 가리켜야 합니다. Busymate DevTools는 대신 모킹을 캡처 경로 안에 둡니다. 차단 규칙이 메서드와 호스트+경로 패턴에 일치하는 모든 요청을 지켜보다가 일치하는 요청에 직접 답합니다. 합성 오류, 끊긴 연결, 또는 원본의 응답과 똑같이 보이는 모킹된 성공으로요. 업스트림 서버에는 절대 연결하지 않습니다.
규칙은 두 곳에서 적용되므로 모든 연결 모드가 포함됩니다. 브라우저, 프록시를 통한 Android, PAC 모드의 iOS에는 프록시 서버가, VPN 모드의 iOS에는 기기 내 VPN 터널이 적용합니다. 전역 규칙은 모든 기기에 적용되고, 기기별 규칙이 그 위에 쌓입니다. 변경 사항은 Realtime으로 퍼지므로 저장한 규칙은 재연결 없이 휴대폰에서 바로 작동합니다.
필요한
이미 캡처 중인 휴대폰과 가짜로 만들고 싶은 엔드포인트.
캡처가 켜진 페어링된 휴대폰. 먼저 iPhone 또는 Android 가이드를 따르세요.
해당 기기의 SSL 프록시 목록에 있는 API 호스트. 경로로 일치시키는 규칙은 복호화된 호스트에서만 경로를 볼 수 있습니다.
응답하려는 호출의 메서드, 호스트, 경로와 앱이 돌려받기를 기대하는 본문.
스크립트 변형에만 해당: 역할에 관리자 계층의 스크립트 권한이 있어야 합니다. 일반 Mock 규칙에는 특별한 역할이 필요 없습니다.
순서대로
1~4단계로 고정 모킹이 완성됩니다. 5단계와 6단계는 고정 본문으로는 할 수 없는 두 가지, 즉 한 번만 발동하기와 응답을 계산하기를 다룹니다.
- 01
호스트가 복호화되었는지 확인하기
대시보드 피드를 열고 해당 엔드포인트로 가는 실제 요청을 찾으세요. 그 행에 복호화된 본문이 보이면 준비된 것입니다. 호스트가 여전히 암호화됨으로 표시되면 행의 호스트 작업이나 기기 설정에서 기기의 SSL 프록시 목록에 추가하고 호출을 다시 일으키세요. 암호화된 채 통과하는 호스트에서는 적용기가 호스트 이름만 일치시킬 수 있습니다. 경로가 보이지 않으므로 경로 단위의 정밀한 모킹은 절대 발동하지 않습니다.
- 02
Blocks를 열고 규칙 추가하기
전역 규칙이라면 설정 내비게이션에서 Blocks 페이지를 열고, 이 휴대폰에만 적용할 규칙이라면 기기로 이동한 뒤 Blocks를 여세요. 규칙을 추가하고 메서드(아무 메서드나 일치시키려면 비워 두기)와 패턴을 입력합니다. 패턴은 브레이크포인트가 쓰는 것과 같은 호스트+경로 와일드카드입니다. 호스트, 슬래시, 경로, 그리고 변하는 구간마다 별표를 넣습니다.
- 03
Mock을 선택하고 응답 만들기
작업을 Mock으로 설정하세요. Block은 호출을 실패시키고 Drop은 네트워크가 사라진 것처럼 보이게 하지만, Mock은 호출을 만족시키기 위한 것입니다. 상태 코드(기본값 200), 앱이 확인할 헤더, 그리고 본문을 설정하세요. 앱이 파싱하는 Content-Type을 지정하세요. 텍스트 응답을 받은 JSON 클라이언트는 한 바이트도 읽기 전에 실패합니다. JSON으로 저장하면 규칙은 다음과 같습니다.
기능 플래그 호출에 고정 본문으로 응답하는 Mock 규칙 json{ "enabled": true, "method": "GET", "pattern": "api.example.com/v1/feature-flags", "action": { "type": "mock", "status": 200, "headers": { "Content-Type": "application/json" }, "body": "{\"flags\": {\"newCheckout\": true}}" } } - 04
저장하고, 호출을 일으키고, 피드 확인하기
규칙을 저장하고 앱을 사용하세요. 다음 일치 요청은 캡처 경로를 벗어나지 않고 응답되며, 여전히 피드에 모킹됨으로 표시되어 나타납니다. 그래서 정확히 무엇이 가짜였는지 보고 규칙이 기대대로 동작했는지 확인할 수 있습니다. 앱에는 평범한 서버 응답만 보입니다. 합성 응답은 내부용이나 식별용 헤더를 전혀 담지 않으므로 응답의 어떤 것도 가로채기를 드러내지 않습니다.
끝나면 활성화 스위치로 규칙을 끄세요. 비활성화된 규칙은 비용이 없고 다음을 위해 형태를 유지합니다.
- 05
실행 횟수 제한으로 정확히 한 번만 발동시키기
어떤 모킹은 한 번만 일어나야 합니다. 대표적인 예가 앱이 토큰이 만료됐다고 믿고 갱신 흐름을 실행하게 만드는 합성 401입니다. 모든 요청에 그렇게 답하면 앱은 갱신하고, 재시도하고, 또 401을 받고, 영원히 돕니다. Max runs 필드는 규칙이 발동할 수 있는 횟수를 제한합니다. 제한에 도달하면 스스로 비활성화되고 편집기에 자동 비활성화 배지가 표시되어, 직접 끈 규칙과 구별됩니다.
횟수는 기기별로 추적되며 재연결과 앱 재시작 후에도 유지되므로, 제한 1인 규칙은 그 휴대폰에서 세션마다가 아니라 통틀어 한 번만 발동합니다. 제한이 있는 전역 규칙은 제한을 다 쓴 기기에서만 억제되고 기기군의 다른 모든 휴대폰에서는 계속 발동합니다. BusyBro에게 자연어로 특정 호스트에 대한 일회성 모킹 401을 요청할 수도 있으며, 같은 규칙을 작성해 줍니다.
일회성 401 — 일반 모킹과 동일하고 제한 1만 추가 json{ "enabled": true, "method": "GET", "pattern": "api.example.com/v1/me", "action": { "type": "mock", "status": 401, "headers": { "Content-Type": "application/json" }, "body": "{\"error\": \"token_expired\"}" }, "maxRuns": 1 } - 06
스크립트로 본문 계산하기
Mock 본문은 고정된 문자열 하나입니다. 응답이 요청에 따라 달라져야 할 때—되돌려 주는 id, 타임스탬프, 실제 응답에 덧씌운 필드—규칙의 작업을 Script로 바꾸거나 Settings, 그다음 Scripts에서 독립 스크립트를 만드세요. 요청, 응답, 헬퍼 객체에 대한 자동 완성이 있는 코드 편집기와, 실제 캡처된 항목에 스크립트를 실행해 실시간 트래픽을 건드리지 않고 전후 차이를 보여 주는 Test 패널을 얻습니다. 시험 실행은 실제 프록시와 동일한 샌드박스를 쓰므로 테스트 통과는 곧 실제 동작을 뜻합니다.
예외를 던지거나 시간 초과된 스크립트는 열린 상태로 실패합니다. 원본 바이트가 전달되고 항목은 검사기에 표시되므로, 망가진 스크립트가 연결을 막거나 앱에 자신을 드러내는 일은 없습니다. 스크립트는 캡처 경로에서 임의 코드를 실행하므로 관리자 계층입니다.
계산된 JSON 본문으로 단락시키는 요청 훅 javascriptfunction onRequest(req) { if (req.path.startsWith("/v1/feature-flags")) { // computed per request — the upstream is never contacted return Response.json({ flags: { newCheckout: true, seed: Date.now() } }, { status: 200 }); } // no return → forward unchanged }
잘못될 수
죽은 것처럼 보이는 규칙은 거의 항상 자기가 볼 수 없는 것과 일치시키려 하고 있습니다.
규칙이 전혀 발동하지 않음
해당 기기에서 호스트가 복호화되었는지(경로 패턴에는 필수) 확인한 뒤, 패턴 철자와 메서드가 일치하거나 비어 있는지 확인하세요. 실제 요청의 피드 행에 복사할 정확한 호스트와 경로가 있습니다.
앱이 갱신 루프에 갇힘
합성 401이 모든 요청에 발동하고 있습니다. Max runs를 1로 설정해 첫 번째 적중 후 규칙이 스스로 비활성화되고 재시도된 요청이 실제 서버에 닿게 하세요.
앱이 모킹된 응답을 거부함
보통 Content-Type 헤더가 없거나 본문 형태가 클라이언트가 파싱하는 것과 맞지 않습니다. 검사기에서 실제 캡처된 응답의 헤더와 본문을 복사해 출발점으로 삼으세요.
규칙에 자동 비활성화 배지가 표시됨
이 기기에서 실행 횟수 제한을 다 썼습니다. Max runs를 지우거나 규칙을 다시 활성화하면 다시 준비됩니다.
스크립트는 실행됐지만 응답은 실제 응답이었음
스크립트가 예외를 던지거나 시간 초과되어 열린 상태로 실패했습니다. 검사기에서 항목을 열고(오류 배지에 메시지와 줄 번호가 있음), 편집기에서 고친 뒤, 다시 활성화하기 전에 같은 항목으로 Test 패널을 다시 실행하세요.
자주 묻는
앱이 모킹된 것을 알아챌 수 있나요?
응답을 검사해서는 알 수 없습니다. 모킹된 200이나 차단된 403은 식별 헤더가 없고 원본의 평범한 응답처럼 보입니다. 가시성은 한 방향입니다. 표시된 항목은 여러분의 피드에만 나타납니다.
VPN 모드의 iOS에서도 되나요, 아니면 프록시를 통해서만 되나요?
둘 다 됩니다. 같은 규칙 엔진이 iOS VPN 터널 안과 프록시 서버에서 실행되므로, 두 모드의 iOS, 프록시를 통한 Android, 브라우저가 모두 규칙을 따릅니다.
규칙을 바꾸면 무언가를 다시 배포해야 하나요?
아니요. 규칙은 Realtime으로 기기에 흘러가는 같은 설정에 있으므로 저장하면 새 연결에 즉시 적용됩니다. 이미 열려 있던 keep-alive 연결은 재연결할 때까지 시작 당시의 구성을 유지합니다.