#Clash 트러블슈팅 매뉴얼: 증상별 문제 해결 총정리

켠 후 인터넷이 안 될 때: 먼저 계층을 나누고 시작하세요

「Clash를 켰는데 아무것도 안 열려요」는 가장 흔하면서도 가장 모호한 증상입니다. 원인은 서로 완전히 다른 네 계층에 있을 수 있습니다: 로컬 네트워크 자체가 끊긴 경우, 클라이언트가 실제로 리스닝하지 않는 경우, 시스템이 트래픽을 클라이언트로 넘기지 않는 경우, 또는 트래픽이 코어까지는 도달했지만 규칙이 실패한 출구로 연결한 경우입니다. 진단의 첫 번째 원칙은 계층별로 범위를 좁혀가는 것이며, 처음부터 클라이언트를 재설치하거나 구독을 바꾸지 마세요.

1단계: 로컬 직접 연결이 정상인지 확인

먼저 클라이언트의 시스템 프록시나 TUN 모드를 끄고, 국내 사이트(예: 통신사 공식 홈페이지)에 직접 접속해 보세요. 끈 상태에서도 열리지 않으면 원인은 라우터, 랜선, 통신사 쪽에 있으며 Clash와는 무관하므로 먼저 기본 네트워크를 해결하세요. 직접 연결은 정상인데 프록시를 켠 후 전부 끊긴다면 다음 단계로 진행하세요.

2단계: 포트가 리스닝 중인지 확인

Clash 계열 클라이언트는 기본적으로 7890 포트에서 혼합 프록시(mixed-port, HTTP와 SOCKS를 동시에 지원)를 엽니다. 아래 명령어로 해당 포트가 실제로 사용 중인지 확인하세요:

# Windows(PowerShell 또는 CMD)
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

아무 출력도 없다면 코어가 정상적으로 시작되지 않았다는 뜻입니다—대부분 설정 파일 파싱 실패나 다른 프로그램의 포트 점유가 원인이므로, 클라이언트 크래시 장으로 바로 이동하세요. 포트가 리스닝 중이라면 curl로 프록시 연결 상태를 테스트해 보세요:

curl -x http://127.0.0.1:7890 -sS -o /dev/null -w "%{http_code}\n" \
  https://www.gstatic.com/generate_204

204가 반환되면 「코어 + 현재 노드」 경로는 정상이며 문제는 시스템 프록시 계층에 있으므로 시스템 프록시 미작동 장을 확인하세요. 타임아웃이나 오류가 반환되면 출구 자체에 문제가 있으므로 노드 타임아웃 장을 이어서 확인하세요.

3단계: 규칙 오작동 배제하기

클라이언트를 글로벌(Global) 모드로 전환해 다시 시도해 보세요. 글로벌 모드는 모든 분기 규칙을 건너뛰고 트래픽을 직접 선택한 노드로 일괄 전달합니다. 글로벌 모드는 되는데 규칙 모드는 안 된다면, 규칙이 대상 도메인을 실패한 정책 그룹으로 분배했거나 최종 MATCH 규칙이 DIRECT를 가리키고 있다는 뜻입니다. 세 가지 모드의 분기 로직 차이는 다음 글에서 확인할 수 있습니다: 규칙, 글로벌, 직접 연결 중 어떤 프록시 모드를 선택할까.

노드 타임아웃: 「일부 타임아웃」과 「전체 타임아웃」 구분하기

클라이언트에 표시되는 지연 시간은 테스트 주소로 보내는 HTTP 요청의 응답 시간을 측정한 값으로, 흔히 https://www.gstatic.com/generate_204가 사용됩니다. 타임아웃이 표시된다는 것은 정해진 시간 내에 응답을 받지 못했다는 뜻이며, 원인은 노드 서버, 전송 프로토콜, 특정 포트에 대한 로컬 네트워크 간섭일 수도 있고 테스트 주소 자체의 일시적 문제일 수도 있습니다. 진단 전에 먼저 확인할 질문: 일부 노드만 타임아웃인가, 모든 노드가 함께 타임아웃인가?

모든 노드가 동시에 타임아웃

모든 노드가 함께 빨간불이라면 노드 자체의 문제는 거의 배제할 수 있으며, 우선 세 가지를 의심해야 합니다. 첫째, 로컬 직접 연결이 정상인지—앞 장의 1단계로 돌아가세요. 둘째, 시스템 시간이 정확한지: 대부분의 암호화 프로토콜은 시간 오차에 민감해서 시간대를 수동으로 바꾸거나 가상머신 시계가 어긋나면 핸드셰이크 전체가 실패할 습니다. 시스템 시간을 자동 동기화로 설정한 후 다시 테스트하세요. 셋째, 구독이 전체적으로 만료되었거나 서버 측에서 차단되었는지: 구독 제공업체의 사용자 패널에 로그인해 트래픽과 만료 시간을 확인하고, 필요하면 구독 실패 장에 따라 설정을 다시 가져오세요.

일부 노드만 타임아웃

단일 노드 타임아웃의 가장 흔한 원인은 해당 서버의 부하가 높거나 회선이 불안정한 경우이며, 같은 지역의 다른 노드로 바꾸면 해결됩니다. 특정 노드가 오랫동안 상태가 오락가락한다면 url-test 타입의 정책 그룹을 사용해 코어가 현재 사용 가능한 노드를 자동으로 선택하게 할 수 있습니다. 작성 방법은 다음과 같습니다:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港-01
      - 日本-01
      - 新加坡-01

interval은 자동 재측정 간격(초)이고, tolerance는 신규 노드와 기존 노드의 지연 차이가 이 밀리초 값을 넘어야 전환한다는 의미로, 지연이 비슷한 두 노드 사이를 계속 오가는 현상을 방지합니다. 정책 그룹 구성 방법은 튜토리얼 페이지와 관련 글에서 더 자세히 설명하고 있습니다.

지연은 정상인데 실제로는 사용이 안 될 때

지연 테스트는 「연결이 성립되는지」만 확인하며, 대역폭이나 UDP 여부는 검증하지 않습니다. 게임, 음성 통화는 UDP 전달에 의존하는데, 프로토콜이나 서버 측에서 UDP를 지원하지 않으면 「측정은 초록불인데 게임은 끊김」이라는 엇박자 현상이 나타납니다. 이런 경우는 구독 제공업체에 노드의 UDP 지원 여부를 먼저 문의해야 하며, 클라이언트 쪽에서는 해결할 수 없습니다. 또한 지연 수치는 「나에서 노드까지」 구간만 반영하므로, 노드에서 대상 사이트까지의 구간이 혼잡하면 지연은 낮은데 웹페이지가 안 열리는 상황도 생길 수 있으며, 이때는 출구 지역을 바꾸면 대체로 바로 해결됩니다.

구독 업데이트 실패: 오류를 먼저 확인하고 직접 연결인지 프록시 연결인지 결정하기

구독은 본질적으로 HTTP(S) 주소이며, YAML 설정 파일이나 변환 가능한 노드 목록을 반환합니다. 업데이트가 실패하면 클라이언트가 일반적으로 오류를 표시하는데, 오류 종류마다 대응 방법이 완전히 다르므로 무작정 업데이트 버튼을 반복해서 누르지 마세요.

구독 주소 수동 검증

클라이언트의 오류 정보가 제한적일 때는 curl로 직접 요청을 시뮬레이션해서 클라이언트 문제와 분리해 확인하세요:

# 직접 연결로 가져오기
curl -sS -o sub.yaml -w "%{http_code}\n" "구독 주소"

# 로컬 프록시를 통해 가져오기
curl -x http://127.0.0.1:7890 -sS -o sub.yaml -w "%{http_code}\n" "구독 주소"

200이 반환되고 sub.yaml에서 proxies:로 시작하는 노드 목록이 보이면 구독 자체는 정상이며 문제는 클라이언트 설정에 있습니다(흔한 경우는 User-Agent가 서버에서 거부된 것이므로 클라이언트 식별자를 바꿔서 재시도). 두 명령어 중 하나만 통하고 하나는 안 된다면 구독 도메인이 현재 네트워크 환경에서 간섭받고 있다는 뜻이므로, 통하는 경로를 고정해서 사용하면 됩니다—대부분의 클라이언트는 구독 편집 화면에 「프록시로 업데이트」 스위치가 있습니다.

업데이트는 성공했는데 노드가 바뀌지 않을 때

일부 클라이언트는 구독에 로컬 캐시를 두므로, 업데이트 후 설정의 마지막 업데이트 타임스탬프를 확인하세요. 또한 주의할 점: 설정 파일의 분기 규칙을 수동으로 수정한 후 구독 업데이트 버튼을 누르면, 변경 사항이 서버에서 내려온 내용으로 덮어씌워집니다—장기적으로 규칙을 커스터마이징하려면 구독 파일을 직접 편집하지 말고 클라이언트의 「설정 강화/병합 스크립트」 기능을 사용해야 합니다.

속도 저하: 병목이 어느 구간인지 파악하기

「느리다」는 것은 전체 경로 중 어느 한 구간이라도 문제가 있으면 나타나는 나무통 효과입니다: 로컬 대역폭 상한, 나에서 노드까지의 회선 품질, 노드 서버의 대역폭, 노드에서 대상 사이트까지의 회선, 그리고 암호화 프로토콜 자체의 오버헤드까지 모두 원인이 될 수 있습니다. 속도 문제를 진단할 때 핵심은 어느 구간이 느린지 먼저 파악하는 것이며, 무작정 노드를 바꾸는 것이 아닙니다.

기준값 세우기

먼저 프록시를 끈 상태로 로컬 순수 속도를 측정해 수치를 기록하고, 프록시를 켠 후 글로벌 모드로 전환해 지연이 가장 낮은 노드로 다시 측정하세요. 두 수치의 차이가 「프록시 경로 오버헤드 + 노드 병목」의 총합입니다. 순수 속도 자체가 몇 메가에 불과하다면 어떤 노드로도 해결되지 않습니다. 순수 속도는 높은데 프록시 후 10분의 1 이하로 떨어진다면 다음 단계로 계속 분석하세요.

흔한 원인과 대응책

프록시를 거칠 필요 없는 트래픽은 직접 연결로

속도가 느려지는 숨은 원인은 종종 분기 설정이 제대로 안 된 데 있습니다: 시스템 업데이트, 게임 다운로드, 클라우드 스토리지 동기화 같은 대용량 트래픽은 굳이 출구를 거칠 필요가 없습니다. 규칙 모드에서 이런 도메인이 DIRECT로 분기되는지 확인하고, 필요하면 수동으로 규칙을 추가하세요. 지리 기반 규칙(GEOIP, GEOSITE)이 정확히 매칭되는지는 로컬 데이터베이스가 최신인지에 달려 있으며, 업데이트 방법은 다음 글에서 확인하세요: GeoIP와 GeoSite 데이터베이스 업데이트 방법.

DNS 문제: 오염, 유출, Fake-IP의 선택

「규칙이 작동 안 함」, 「특정 사이트가 안 열림」, 「처음 열 때 유난히 느림」 같은 문제의 상당수는 DNS에 원인이 있습니다. Clash 코어는 자체 DNS 모듈을 내장하고 있으며, 두 가지 강화 모드와 nameserver의 계층 설계를 이해하면 대부분의 난해한 문제를 해결할 수 있습니다.

증상 구분

전형적인 DNS 오염 증상은: 도메인 해석으로 IP는 나오지만 그 IP에 전혀 연결이 안 되거나, 해석 결과가 명백히 대상 사이트가 아닌 경우입니다. 반면 DNS 설정 오류의 증상은 도메인 규칙(DOMAIN-SUFFIX 등)은 정상 매칭되는데 GEOIP 규칙이 뒤섞이거나, 노드를 전환해도 여전히 이전 주소로 접속되는 경우입니다. nslookup이나 dig로 로컬 해석 결과와 공용 DoH 해석 결과를 비교하면 오염 여부를 빠르게 확인할 수 있습니다.

추천 DNS 설정 골격

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.windows.com"
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query

enhanced-mode: fake-ip는 코어가 예약된 대역의 가상 주소로 쿼리에 즉시 응답하게 해서 실제 해석 대기 시간을 없애고, 도메인 규칙이 정확히 매칭되도록 보장합니다—이는 대부분의 클라이언트에서 기본 모드이기도 합니다. 전체 동작 방식, redir-host와의 차이, 예외 처리가 필요한 상황은 다음 글에서 자세히 다룹니다: Fake-IP 모드 동작 원리 상세 설명.

Fake-IP의 대표적인 함정과 예외 목록

실제 IP가 필요한 프로그램은 Fake-IP에서 문제가 생길 수 있습니다: LAN 기기 검색, NTP 시간 동기화, 일부 게임 런처, 역접속이 필요한 P2P 애플리케이션 등입니다. 증상은 이런 프로그램이 198.18.x.x 주소를 받은 후 비정상적으로 동작하는 것입니다. 해결책은 Fake-IP를 끄는 것이 아니라, 관련 도메인을 fake-ip-filter에 추가해서 실제 해석을 거치게 하는 것입니다. 설정을 바꾼 후에도 이전 가상 주소가 시스템에 캐시되어 남아있다면, Windows에서는 ipconfig /flushdns, macOS에서는 sudo dscacheutil -flushcache를 실행해 캐시를 한 번 지워주세요.

시스템 프록시 미작동: 어떤 트래픽이 시스템 프록시를 무시하는가

시스템 프록시의 본질은 운영체제 계층에 「HTTP/SOCKS 프록시는 127.0.0.1:7890에 있다」는 권고를 등록하는 것입니다—강제가 아니라는 점에 주의하세요. 브라우저와 대부분의 최신 애플리케이션은 이를 따르지만, 명령줄 도구, 일부 구형 소프트웨어, Windows의 UWP 앱은 이를 무시합니다. 이 점을 이해하면 「작동 안 함」 문제의 절반은 답이 나옵니다: 프록시가 고장 난 게 아니라 해당 프로그램이 애초에 프록시를 거칠 생각이 없는 것입니다. 두 가지 트래픽 인수 방식의 메커니즘 비교는 다음 글을 먼저 읽어보세요: TUN 모드와 시스템 프록시의 차이점.

Windows: UWP 루프백 제한

Microsoft Store 앱(UWP)은 기본적으로 로컬 루프백 주소 접근이 금지되어 있어, 시스템 프록시가 127.0.0.1을 가리키더라도 스토어 버전 앱의 트래픽은 Clash로 들어가지 못합니다. 대부분의 Windows 클라이언트는 「UWP 루프백 도우미/Loopback 도구」를 내장하고 있으므로 대상 앱을 체크해서 허용하면 됩니다. 시스템 기본 명령어로 수동 허용할 수도 있는데, 예를 들어 Microsoft Store를 허용하려면:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

# 현재 허용 목록 확인
CheckNetIsolation.exe LoopbackExempt -s

명령줄 및 개발 도구

터미널의 git, pip, npm, curl은 시스템 프록시 설정을 읽지 않으므로 환경변수를 명시적으로 선언하거나 TUN 모드로 전체를 인수해야 합니다:

# macOS / Linux(현재 세션에만 적용)
export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"; $env:HTTP_PROXY="http://127.0.0.1:7890"

프록시 설정이 다른 프로그램에 덮어써지거나 적용되지 않을 때

「시스템 프록시」를 켠 후, 운영체제의 프록시 설정 화면에서 직접 확인하세요: Windows는 「설정 → 네트워크 및 인터넷 → 프록시」, macOS는 「시스템 설정 → 네트워크 → 현재 네트워크 서비스 → 세부사항 → 프록시」에서 확인합니다. 주소가 127.0.0.1:7890이 아니라면 흔한 원인은: 다른 프록시 소프트웨어(또는 남은 드라이버)가 설정을 계속 덮어쓰거나, macOS에서 현재 활성화된 네트워크 서비스가 설정이 적용된 서비스와 다른 경우(예: Wi-Fi에 설정했지만 실제로는 유선 연결 사용 중)입니다. 충돌하는 소프트웨어를 종료하고 네트워크 서비스 순서를 확인한 후 스위치를 다시 켜면 됩니다. 이 번거로움을 완전히 피하는 방법은 TUN 모드를 활성화해 가상 네트워크 카드로 네트워크 계층에서 모든 트래픽을 인수하는 것이며, 대가로 관리자 권한이 필요하고 다른 가상 네트워크 카드류 소프트웨어와의 호환성에 주의해야 합니다.

클라이언트 크래시와 시작 실패: 로그에서 답 찾기

클라이언트가 「클릭해도 반응 없음」, 「시작하자마자 꺼짐」, 「실행 중 갑자기 연결 끊김」 같은 문제는 대부분 명확한 로그 흔적이 있으며, 무작정 재설치하는 것보다 먼저 로그를 확인하는 것이 훨씬 효율적입니다. 각 클라이언트는 설정이나 트레이 메뉴에 「로그/앱 디렉터리 열기」 항목을 제공하니, 진단 전에 로그 레벨을 info나 debug로 조정한 후 문제를 다시 재현해 보세요.

시작 즉시 종료: 먼저 설정을 확인하고, 그다음 포트를 확인

가장 흔한 시작 실패는 설정 파일 파싱 오류입니다—YAML은 들여쓰기와 콜론 뒤 공백에 매우 민감해서, 수동 편집 후 공백 하나만 빠져도 설정 전체가 무효가 됩니다. 로그에 구체적인 줄 번호가 표시되니 해당 줄을 수정하세요. 변경 사항이 클 경우 수정하지 않은 구독 설정으로 먼저 바꿔서 클라이언트 자체가 정상인지 확인하면 「설정 문제」와 「프로그램 문제」를 구분할 수 있습니다. 두 번째로 흔한 원인은 포트 충돌입니다: 7890이나 9090(외부 제어 포트)이 다른 프로그램에 점유된 경우로, 로그에 bind: address already in use 같은 문구가 나타납니다. 위에서 소개한 netstat/lsof로 점유 중인 프로그램을 찾거나, 설정에서 다른 포트로 변경하세요.

실행 중 연결 끊김이나 크래시

TUN 모드에서 갑자기 연결이 끊긴다면 가상 네트워크 카드 드라이버와 다른 네트워크 소프트웨어(가상머신, 다른 프록시 도구, 일부 보안 소프트웨어)의 충돌을 우선 의심하세요. 로그에는 보통 네트워크 카드 생성이나 라우팅 등록 실패 기록이 함께 나타납니다. 시스템이 절전 모드에서 깨어난 후 네트워크가 복구되지 않는 것은 모든 플랫폼에서 존재하는 오래된 문제로, TUN이나 시스템 프록시 스위치를 한 번 다시 켜면 대체로 복구됩니다. 메모리가 계속 증가해서 시스템에 의해 강제 종료되는 경우는 구독 노드 수가 매우 많거나 규칙 세트가 과도한 설정에서 자주 발생하며, 구독을 정리하고 불필요한 규칙 구독 세트를 줄이면 뚜렷하게 개선됩니다.

초기화와 클라이언트 교체

프로그램 자체의 문제로 확인되었다면 삭제 후 남은 앱 데이터 디렉터리를 수동으로 정리하고 재설치하는 것이 덮어쓰기 설치보다 확실합니다(구독 주소는 미리 백업해두세요). 같은 구독은 여러 클라이언트에서 공통으로 사용할 수 있으므로, 특정 클라이언트가 사용 중인 시스템과 안 맞을 때는 다른 클라이언트로 바로 바꿔보는 것도 비용이 적게 드는 방법입니다: 각 플랫폼별 추천 순서와 차이는 클라이언트 비교를 참고하고, 설치 파일은 모두 클라이언트 받기 페이지에서 받으며 각 플랫폼의 Clash Plus를 우선 추천합니다.

모바일 전용 문제: Android와 iOS는 각자 다른 함정이 있습니다

모바일 환경의 문제 패턴은 데스크톱과 다릅니다: 시스템이 백그라운드 프로세스와 VPN 통로 관리에 더 적극적으로 개입하며, 문제는 종종 설정이 아니라 시스템 정책에 있습니다. 이 장에서는 플랫폼별로 나눠서 설명합니다.

Android: VPN 권한과 백그라운드 유지

Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 인수하므로, 처음 실행할 때 「VPN 연결 생성」 시스템 팝업에 동의해야 합니다. 당시 거부를 눌렀다면 이후 「시작 버튼을 눌러도 반응 없음」 현상이 나타나며, 시스템 설정의 VPN 관리에서 해당 앱을 찾아 다시 권한을 부여하면 됩니다. 두 번째로 큰 문제는 백그라운드 종료입니다: 중국산 커스텀 시스템의 배터리 최적화 기능이 장기 상주 VPN 서비스를 강제 종료해서 「쓰다 보면 끊김」, 「화면 잠금 후 한동안 있으면 실패」로 나타납니다. 해결책은 클라이언트를 배터리 최적화 예외 목록에 추가하고, 자동 시작과 백그라운드 실행을 허용하며, 최근 작업 목록에서 고정하는 것입니다. 또한 시스템의 「항상 켜진 VPN」과 「VPN 없이는 연결 차단」 옵션에 주의하세요: 전자는 생존율을 높이고, 후자는 클라이언트가 비정상 종료될 때 바로 인터넷을 끊어버리므로 연결 끊김 문제를 진단할 때 이 두 스위치의 상태를 확인해야 합니다. 앱별 프록시(Access Control) 설정 오류도 종종 오작동으로 오인되는데, 특정 앱만 프록시를 거치지 않는다면 먼저 그 앱이 목록에서 제외되어 있는지 확인하세요.

iOS: App Store 경로로 받고, 설정 용량에 주의

iOS에서는 네트워크 확장(Network Extension)으로 트래픽을 인수하는데, 시스템이 이런 확장의 백그라운드 메모리를 엄격하게 제한합니다. 구독에 노드 수가 너무 많거나 규칙 세트가 대량으로 딸려 있으면 확장 프로세스가 한도를 초과해 시스템에 의해 강제 종료될 수 있으며, 「연결 스위치가 자동으로 꺼짐」으로 나타납니다. 대응책은 설정을 간소화하는 것입니다: 구독 제공업체에 노드 수가 적은 경량 버전 구독을 요청하거나, 클라이언트에서 사용하지 않는 규칙을 정리하세요. iOS 클라이언트는 App Store에서 받으며, Clash Plus(공식 사이트 clashplus.io)를 우선 추천합니다. 스토어 링크와 설명은 다운로드 페이지 iOS 섹션에서 확인하세요. Wi-Fi와 셀룰러 네트워크를 전환한 후 잠깐 연결이 끊기는 것은 확장이 통로를 재구성하는 정상적인 현상이며, 몇 초 후에도 복구되지 않으면 스위치를 수동으로 다시 켜면 됩니다.

다른 방법: PC가 모바일 기기를 대신 프록시하기

TV, 게임기, 또는 클라이언트를 설치하기 어려운 기기는 「한 대의 PC에서 Clash를 실행하고 집 전체가 공유하는」 방식을 사용할 수 있습니다: allow-lan을 켠 후, 다른 기기에서 프록시를 PC의 LAN IP와 혼합 포트로 지정하면 됩니다. 전체 절차(bind-address 값과 방화벽 허용 포함)는 다음 글을 확인하세요: Clash LAN 프록시 공유 설정.

아직 해결되지 않았다면? 다음 단계

증상별 장을 모두 살펴봐도 해결되지 않을 때는 다음 순서로 진행하세요: 첫째, 로그 레벨을 debug로 조정해 문제를 다시 재현하세요. 로그의 실제 오류 원문은 증상 자체보다 훨씬 많은 정보를 담고 있는 경우가 많습니다. 둘째, 최소화 검증을 하세요—깨끗한 설정으로 교체, 다른 클라이언트로 교체, 다른 네트워크 환경으로 교체하는 세 가지 변수를 하나씩 바꿔보면 문제를 특정 구간으로 좁힐 수 있습니다. 셋째, FAQ 페이지에서 분류별로 짧은 질문과 답변을 훑어보세요. 자잘한 문제들(자동 시작, 설정 파일 위치, 모드 전환 미작동)은 대부분 여기서 바로 답을 찾을 수 있습니다. 기본 조작이 익숙하지 않다면 사용 가이드로 돌아가서 핵심 흐름을 다시 따라 해보세요. 「난해한 문제」로 보였던 것들이 실제로는 어떤 단계를 빠뜨린 것일 때가 적지 않습니다.