V2Ray 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 그룹의 가장 중요한 역할은 연결 프로토콜을 바꾸는 것이 아니라 출처를 분리하는 것입니다. 구독 출처마다 그룹을 따로 만들면 업데이트 범위, 항목 소속, 비활성화 범위를 명확하게 관리할 수 있습니다. v2rayN에서는 보통 ‘구독 그룹’ 관련 메뉴에서 이름과 주소를 추가하고, v2rayNG와 v2flyNG에서는 구독 설정에서 출처를 관리합니다. 클라이언트마다 메뉴 이름은 다를 수 있지만, 출처를 등록하고 해당 출처를 업데이트한 뒤 가져온 결과를 확인하는 순서는 같습니다.

출처별로 그룹을 만들고 표시 범위 정하기

그룹 이름은 ‘일상용 출처’, ‘예비 출처’, ‘수동 설정’처럼 용도를 나타내는 것이 좋습니다. 인증 정보, 전체 구독 주소, 결제 정보는 이름에 넣지 마세요. 비슷한 항목을 제공하는 출처라도 그룹은 분리해 두세요. 특정 출처의 업데이트가 중단되면 여러 출처가 섞인 목록에서 항목을 일일이 찾지 않고 해당 그룹만 비활성화할 수 있습니다. 수동 항목은 구독에서 생성된 항목과 섞이지 않도록 별도 그룹에 두는 편이 좋습니다.

구독 주소를 입력할 때는 전체 쿼리 매개변수를 그대로 유지하세요. 일부 구독은 주소에 포함된 토큰으로 계정을 식별하므로 물음표 뒤의 내용을 임의로 삭제하면 업데이트에 실패할 수 있습니다. QR 코드나 클립보드에서 가져오는 경우 앞뒤 공백, 줄바꿈, 전각 문자가 없는지 확인하세요. 인증 정보가 포함된 주소를 공개 변환 서비스에 입력하지 마세요. 형식 변환은 신뢰할 수 있는 로컬 방식으로 처리하고, 자세한 구조는 구독 링크 형식 안내를 참고하세요.

필터가 적용되는 단계 이해하기

‘검색’, ‘표시 필터링’, ‘가져오기 필터링’은 서로 다릅니다. 검색은 보통 목록에 표시되는 항목만 바꾸며 서버를 삭제하지 않습니다. 가져오기 필터링은 조건에 맞지 않는 항목을 현재 그룹에 아예 추가하지 않을 수 있습니다. 삭제는 로컬 항목 목록을 변경합니다. 조정하기 전에 옵션 설명을 읽고 다음 구독 업데이트에도 필터가 적용되는지 확인하세요. 확실하지 않다면 목록 검색을 사용하고, 구독 설정에 복잡한 표현식을 바로 입력하지 마세요.

현재 클라이언트가 정규식을 지원한다면 간단하고 범위가 분명한 규칙으로 이름을 필터링할 수 있습니다. 먼저 적은 수의 항목에서 확인한 뒤 전체 출처에 적용하세요. 구독 이름은 제공업체가 정하므로 접두사, 공백, 다양한 언어가 포함될 수 있습니다. 따라서 이름으로 필터링해도 실제 지리적 위치를 판별할 수는 없습니다. 필터 결과가 비어 있다면 먼저 필터를 해제하고 다시 업데이트해 원래 구독에 항목이 있는지 확인한 뒤 대소문자, 구분 기호, 표현식 문법을 점검하세요.

^(일상|예비)-
^(?!.*테스트).*$

위 두 줄은 서로 독립적인 정규식 예시입니다. 첫 번째는 ‘일상-’ 또는 ‘예비-’로 시작하는 이름을 찾고, 두 번째는 이름에 ‘테스트’가 포함된 항목을 제외합니다. 정규식 지원이 명시된 필드에서만 사용하세요. 일반 검색창에서는 이러한 기호가 정규식으로 처리되지 않을 수 있습니다. 이름 필터링은 목록 관리에만 쓰이며 프로토콜 호환성, 서비스 작동 여부, 예상한 경로를 보장하지 않습니다.

업데이트 후 항목 변경 사항 확인하기

지정한 그룹을 업데이트한 뒤에는 프로토콜 유형, 주소, 포트, 전송 방식이 제대로 해석됐는지 먼저 확인하세요. 항목 수가 달라진 것은 출처 변경, 필터 규칙, 형식 인식 차이 때문일 수 있으며 클라이언트가 설정을 잃었다는 뜻은 아닙니다. 그룹 전체가 사라지거나 비어 있다면 업데이트 응답과 파싱 오류를 먼저 확인한 뒤 이전 필터 조건을 복원하세요. 업데이트 버튼을 반복해서 눌러도 형식 호환성 문제는 해결되지 않으며, 출처 측 요청 제한이 걸릴 수 있습니다.

구독 항목의 이름이나 전송 매개변수를 직접 수정해 장기적인 변경 사항을 유지하려 하지 마세요. 다음 업데이트에서 수정 사항이 덮어써지거나 항목이 다시 생성될 수 있습니다. 임시 수정이 꼭 필요하다면 항목을 수동 그룹으로 복사하고 용도를 분명히 표시한 뒤 원본과 달라진 점을 기록하세요. 원본 구독은 그대로 유지해야 문제가 출처 데이터에서 비롯됐는지 로컬 수정에서 비롯됐는지 확인할 수 있습니다.

그룹을 바꿔도 현재 사용 중인 서버가 바뀌는 것은 아닐 수 있습니다. 업데이트 후에는 현재 선택된 항목을 다시 확인하세요. 특히 기존 항목이 삭제되거나 새로 생성된 경우에는 반드시 확인해야 합니다. 모바일에서는 변경 사항을 적용하기 위해 서비스를 다시 시작해야 할 수도 있습니다. 목록에서 선택 항목이 강조 표시되는 것만 믿지 말고 시작 로그의 실제 대상과 아웃바운드를 확인하세요. 목록 정리를 마친 뒤 라우팅을 설정해야 출처 관리 문제를 분할 라우팅 오류로 오인하지 않습니다.

DNS 설정 및 조회 경로

DNS 문제는 세 가지로 나눠 살펴봐야 합니다. 누가 조회를 시작하는지, 누가 조회를 처리하는지, 요청이 어떤 경로로 상위 DNS 서버에 도달하는지 확인하세요. 브라우저, 운영체제, 프록시 코어, TUN 트래픽 가로채기 구성 요소가 각각 DNS를 처리할 수 있습니다. 클라이언트에서 DNS 주소를 바꿔도 모든 앱이 즉시 해당 주소를 사용하는 것은 아닙니다. 앱 자체의 암호화 DNS, 시스템 캐시, 기존 연결이 관찰 결과에 계속 영향을 줄 수 있습니다.

내장 DNS의 역할부터 확인하기

프록시 코어의 내장 DNS는 보통 내부 도메인 조회, 라우팅 판단, 특정 아웃바운드 동작에 사용되며 시스템의 기본 DNS 서버로 자동 지정되는 것은 아닙니다. 시스템 프록시 모드에서는 일부 앱이 시스템 DNS로 먼저 조회한 뒤 IP를 프록시에 전달하고, 다른 앱은 도메인을 프록시 진입점에 전달합니다. 두 경로의 DNS 동작은 서로 다릅니다. 시스템 DNS 조회를 가로채려면 보통 TUN 측의 DNS 하이재킹이나 이에 해당하는 시스템 설정이 추가로 필요합니다.

v2rayN의 DNS 화면은 사용하는 코어에 따라 설정 항목이 나뉠 수 있습니다. v2rayNG의 원격 DNS, 로컬 DNS, 관련 라우팅 옵션도 현재 모드를 함께 고려해 해석해야 합니다. ‘원격’이라는 표현만 보고 트래픽이 반드시 프록시를 통과한다고 판단하지 마세요. 먼저 클라이언트 기본 설정을 유지한 채 일반 연결이 작동하는지 확인한 다음 상위 DNS 주소와 도메인별 라우팅을 조정하세요. DNS 설정을 전부 바꾸기 전에 기존 규칙과 보조 DNS 서버의 용도를 기록해 두세요.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

이 Xray 스타일 DNS 조각은 도메인별 조회 서버와 대체 DNS 서버 설정을 보여 주며 모든 네트워크에 적합하다고 보장하지 않습니다. domains는 해당 도메인에 사용할 서버를 선택하고, skipFallback은 그 서버가 다른 도메인의 일반적인 폴백에 참여하지 않도록 합니다. 선택된 도메인이 다른 서버를 절대 시도하지 않는다는 뜻은 아닙니다. 전체 폴백 동작은 다른 옵션의 영향도 받습니다. 실제 설정에서 상위 DNS 서버에 연결할 수 있는지, 어떤 아웃바운드 경로를 쓰는지 확인해야 합니다.

암호화 DNS와 부트스트랩 조회

도메인 이름으로 지정된 암호화 DNS 서비스를 사용하려면 암호화 연결을 만들기 전에 먼저 해당 서비스 주소를 알아야 합니다. 이를 부트스트랩 조회 문제라고 합니다. 부트스트랩 조회가 아직 연결되지 않은 동일한 서비스를 거쳐야 한다면 순환 의존성이 생깁니다. 명확하게 도달할 수 있는 부트스트랩 경로를 사용하거나 현재 코어가 지원하는 정적 매핑 방식을 적용하세요. 일반 DNS 주소를 암호화 DNS 주소로 바꾸기만 하면 조회 경로가 완성된다고 가정하지 마세요.

원격 프록시 서버의 도메인도 이 경로에 포함됩니다. 서버 주소를 프록시를 통해서만 조회할 수 있고 프록시는 서버에 먼저 연결해야 한다면, 시작 과정이 선행 DNS 조회에서 멈출 수 있습니다. 문제를 해결할 때는 서비스가 시작되기 전에 서버 도메인을 조회할 수 있는지, 상위 연결이 자기 자신으로 잘못 되돌아오지 않는지 먼저 확인하세요. 암호화 DNS는 조회 전송을 보호할 뿐 라우팅, 서버 인증서, 잘못된 시스템 시간을 자동으로 바로잡지는 않습니다.

IPv4, IPv6 및 캐시의 영향

UseIP는 두 유형의 주소 결과를 모두 사용할 수 있게 하지만 시스템의 IPv6 연결이 정상이라는 뜻은 아닙니다. 네트워크가 IPv6 주소를 제공해도 외부 연결이 불가능하다면 앱이 연결 실패를 기다린 뒤 폴백하면서 첫 접속이 느려질 수 있습니다. IPv4와 IPv6의 실제 경로를 비교한 다음 IPv4 전용 조회 방식을 사용할지 결정하세요. 특정 조회 유형을 끄더라도 앱이 자체 조회를 하거나 IP를 직접 사용하는 동작까지 모두 막을 수는 없습니다.

DNS를 검증할 때 시스템 조회 도구로 확인한 결과는 시스템이 사용하는 DNS 서버의 동작만 보여 줄 수 있으며, 프록시 코어의 내장 DNS가 정상이라는 뜻은 아닙니다. 클라이언트 로그와 앱의 연결 기록도 함께 확인하세요. 설정을 바꾼 뒤에는 시스템, 브라우저, 코어의 캐시를 고려해야 합니다. 상위 DNS 서버를 계속 바꾸기보다 테스트 대상의 캐시를 하나씩 지우거나 재시작하는 편이 결과를 해석하기 쉽습니다. 캐시가 만료되지 않았다면 한 번 접속에 성공해도 새 DNS 서버가 조회에 참여했다고 볼 수 없습니다.

도메인 조회는 되지만 접속할 수 없다면 반환된 주소와 라우팅 아웃바운드가 일치하는지 계속 확인하세요. DNS 단계에만 머물러서는 안 됩니다. LAN의 짧은 호스트 이름만 작동하지 않는다면 검색 도메인과 로컬 DNS 서비스가 가로채기 대상인지 확인하세요. 사내 도메인, 프린터 이름, 가정용 네트워크 장치는 로컬 DNS에 의존할 수 있으므로 모두 공용 DNS 서버로 보내기보다 명확한 로컬 조회 예외를 설정하는 편이 좋습니다.

FakeDNS 및 도메인 매핑

FakeDNS는 조회된 도메인에 합성 IP를 할당하고 내부적으로 도메인과 주소의 매핑을 관리합니다. 앱이 해당 주소로 연결하면 트래픽 가로채기 구성 요소가 원래 도메인을 복원한 뒤 도메인별 라우팅을 적용하거나 프록시 아웃바운드에 넘겨 조회하도록 할 수 있습니다. 합성 주소는 대상 서버의 실제 주소가 아니며 새로운 원격 서버도 아닙니다. 앱이 먼저 실제 IP를 조회해 도메인 정보를 잃는 상황을 줄이고 도메인 정보를 유지하는 데 도움이 됩니다.

매핑 경로 전체가 갖춰져야 활성화 가능

FakeDNS가 작동하려면 최소 세 가지가 함께 구성되어야 합니다. 조회가 지정된 DNS 서버에 전달되고, 합성 주소로 연결되는 트래픽이 같은 가로채기 경로에 포착되며, 연결 처리 단계에서 도메인을 복원할 수 있어야 합니다. DNS 서버 목록에 이름만 추가하고 해당 트래픽을 가로채지 않으면 앱이 합성 IP를 일반 게이트웨이로 직접 보낼 수 있습니다. 반대로 스니핑만 설정해도 시스템 DNS 조회가 자동으로 FakeDNS에 전달되지는 않습니다.

먼저 합성 주소를 담당할 구성 요소를 정하세요. v2rayN의 TUN 트래픽 가로채기 구성 요소에 자체 가짜 IP 기능이 있다면 Xray FakeDNS를 무작정 추가로 켜지 마세요. 두 구성 요소가 각각 주소를 할당하고 캐시를 관리하면 도메인을 복원할 때 매핑을 찾지 못할 수 있습니다. v2rayNG와 v2flyNG도 메뉴와 지원 범위가 다르므로 현재 코어와 클라이언트 기능을 확인해야 합니다. 설정 이름이 비슷하다고 구현 방식도 같다고 추정하지 마세요.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

이 Xray 스타일 기능 조각은 전체 DNS 가로채기 설정이 아닙니다. 주소 풀은 테스트 전용 주소 범위를 사용하지만 현재 환경에서 충돌이 발생하지 않는다는 뜻은 아닙니다. LAN, 기업 네트워크 또는 다른 가상 인터페이스가 이미 해당 범위를 사용한다면 먼저 설정을 조정하세요. 주소 풀 크기는 매핑 용량을 결정하며 동시 연결 수의 상한과는 다릅니다. 용량을 늘려도 DNS 조회를 가로채지 못하거나 매핑을 복원하지 못하는 문제는 해결되지 않습니다.

인바운드 복원 및 스니핑의 한계

Xray가 해당 트래픽을 직접 처리하는 방식이라면 관련 인바운드에서도 FakeDNS에 맞는 복원 기능을 활성화해야 합니다. 설정은 합성 주소 연결을 수신하는 인바운드에 적용해야 하며 아무 리스닝 진입점에나 설정해서는 안 됩니다. 아래는 일반적인 스니핑 조각입니다. 실제 인바운드 구조에 맞춰 사용해야 합니다. 상위 단계에서 트래픽 가로채기 구성 요소가 이미 도메인을 복원한다면 해당 구성 요소의 설정 방법을 따르세요.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

일반 HTTP 또는 TLS 스니핑과 FakeDNS 매핑은 서로 다른 출처의 정보입니다. 전자는 앱 프로토콜에서 도메인을 추출하려 하고, 후자는 이전 조회 기록에 의존합니다. 일부 프로토콜, 암호화 핸드셰이크 방식, IP 직접 요청에서는 사용할 수 있는 도메인을 얻지 못할 수 있습니다. 스니핑이 모든 대상의 이름을 반드시 복원한다고 생각해서는 안 됩니다. 스니핑이 라우팅에만 영향을 주는지 연결 대상을 바꾸는지도 현재 코어의 옵션에 맞춰 이해해야 합니다.

캐시, 설정 전환 및 호환성 처리

활성화한 뒤 아직 캐시되지 않은 도메인을 조회해 앱이 합성 주소를 받는지 확인하고, 연결 시 해당 도메인이 복원되는지 살펴보세요. 서비스를 중지하거나 트래픽 가로채기 구성 요소를 바꾸면 앱에 이전 합성 IP가 남아 있을 수 있습니다. 새 서비스에는 그 매핑이 없어 일부 사이트에 갑자기 접속할 수 없는 현상이 생길 수 있습니다. 이때는 주소 풀을 늘리거나 원격 서버를 계속 바꾸지 말고 관련 DNS 캐시를 지운 뒤 앱을 다시 시작하세요.

LAN 서비스 검색, 조회 결과의 주소를 검사하는 프로그램, 실제 주소에 의존하는 진단 도구는 합성 주소와 맞지 않을 수 있습니다. 이런 대상에는 실제 주소를 반환하는 명시적인 조회 예외를 우선 설정하고, DNS와 연결 경로 양쪽에 예외가 적용되는지 확인하세요. 브라우저에 내장된 암호화 DNS가 가로채기 DNS를 우회하면 같은 앱의 요청끼리도 서로 다른 경로를 사용할 수 있으므로 문제를 확인할 때 해당 설정 상태를 기록하세요.

활성화 전후로 분명한 이점이 없다면 일반 DNS 설정을 유지하는 편이 관리하기 쉽습니다. 되돌릴 때는 트래픽 가로채기를 중지하고 DNS 설정을 복원한 다음 캐시를 지우고 앱을 다시 시작하세요. 이후 직접 연결과 프록시 대상 모두를 검증합니다. FakeDNS 필드만 지운 채 시스템에 합성 주소가 남도록 두지 마세요. 신뢰할 수 있는 비교 결과를 얻으려면 설정과 캐시를 함께 복원해야 합니다.

사용자 지정 아웃바운드 및 설정 롤백

아웃바운드는 프록시 코어에서 연결이 최종적으로 나가는 방식을 정의하며 라우팅은 태그로 해당 아웃바운드를 참조합니다. 일반적인 용도는 직접 연결, 프록시, 차단이며 이미 실행 중인 로컬 프록시 진입점에 연결할 수도 있습니다. 사용자 지정 아웃바운드는 명확한 경로 요구를 해결할 때 적합하며 일반 서버를 가져오는 대신 사용하면 안 됩니다. 시작 전에 각 태그가 어떤 서비스와 연결되는지, 어디에서 리스닝하는지, 해당 서비스가 중지되면 어떻게 되는지 파악하세요.

태그는 설정 내부의 참조 관계입니다

tag는 직접 지정하는 식별자이며 프로토콜 기능을 자동으로 생성하지 않습니다. 라우팅에 proxy를 썼다면 설정에도 같은 이름의 아웃바운드가 있어야 합니다. 이름이 비슷해도 서로 같은 것으로 취급되지 않습니다. 네이티브 Xray 설정에서는 첫 번째 아웃바운드가 보통 규칙에 일치하지 않는 트래픽의 기본 경로가 되므로 순서도 중요합니다. 클라이언트가 생성하는 설정에는 기본 규칙이 추가될 수 있으므로 편집 창의 일부만 보지 말고 실제 실행 구조를 확인하세요.

다음은 로컬 경로를 테스트할 수 있는 완전한 Xray 스타일 설정입니다. 로컬 앱이 SOCKS 인바운드에 연결하면 일반 대상은 로컬의 다른 SOCKS 서비스로 전달하고 사설 주소는 직접 연결합니다. 원격 서버 인증 정보는 포함되어 있지 않습니다. 참조한 상위 서비스가 해당 포트에서 실제로 실행 중이어야 합니다. 상위 서비스가 현재 인바운드로 다시 연결되지 않도록 하세요. 순환 전달이 발생할 수 있습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10810,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10809
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙보다 프로토콜과 포트를 먼저 확인하기

사용하기 전에 10810이 다른 프로그램에서 사용 중이지 않은지, 10809에서 SOCKS 서비스가 제공되는지 확인하세요. 포트 이름이 ‘프록시 포트’라고 해서 HTTP 프록시 포트를 SOCKS 아웃바운드에 넣을 수 있는 것은 아닙니다. 여기의 포트는 테스트를 위한 별도 값이며 클라이언트 기본값을 의미하지 않습니다. 인증되지 않은 진입점이 실수로 LAN에 노출되지 않도록 리스닝 주소를 로컬 루프백으로 제한하세요. 원격 접속이 필요하다면 인증, 방화벽, 접근 범위를 별도로 설계해야 합니다.

이 예시에서는 TCP 경로 테스트만을 위해 인바운드 UDP를 비활성화했습니다. 이 설정으로 모든 UDP 앱을 처리할 수 있다고 추론해서는 안 됩니다. UDP를 추가하려면 인바운드, 상위 SOCKS 서비스, 이후 연결 경로가 모두 UDP를 지원하는지 확인해야 합니다. 직접 연결과 차단 아웃바운드는 정의만으로 작동하지 않습니다. 라우팅 규칙에 일치하거나 기본 경로가 되어야 사용됩니다. block이라는 아웃바운드를 추가해도 대상이 자동으로 차단되지는 않습니다.

사용자 지정 설정을 적용할 수 있는 범위

v2rayN에서 사용자 지정 설정 메뉴를 사용할 때는 파일 문법에 맞는 코어를 선택하고 클라이언트가 로컬 리스닝 포트를 어떻게 인식하는지 확인하세요. 일부 관리 옵션은 해당 파일을 더 이상 수정하지 않을 수 있으며 시스템 프록시가 이전 포트를 계속 가리킬 수도 있습니다. 모바일 클라이언트는 데스크톱과 가져오기 기능이 다르므로 현재 클라이언트가 지원하는 설정 유형을 사용하세요. 파일을 저장할 수 있다는 사실만으로 서비스가 예상대로 시작된다고 볼 수 없습니다.

여러 프록시를 연결하면 의존성과 문제 해결 비용이 늘어납니다. 두 프록시를 연결하기 전에 상위와 하위 프록시를 각각 검증하고 어느 단계에서 다른 단계의 출구 트래픽을 다시 가로채는지 확인하세요. 소수의 도메인에 서로 다른 경로를 지정하려는 목적이라면 불필요한 프록시 계층을 추가하지 말고 명확한 라우팅과 개별 아웃바운드를 우선 사용하세요. 프로토콜 선택은 주요 프로토콜 비교를 참고할 수 있지만 실제 전송 성능은 연결 경로에 따라 달라집니다.

설정한 역순으로 되돌리기

시작에 실패하면 첫 번째로 표시되는 명확한 오류부터 확인하세요. JSON 문법 오류, 알 수 없는 필드, 포트 충돌, 아웃바운드 참조 누락은 각각 다르게 처리해야 합니다. 시작은 성공했지만 연결할 수 없다면 상위 서비스가 리스닝 중인지, 프로토콜이 일치하는지, 기본 아웃바운드가 올바른지 확인하세요. 로그 상세도를 일시적으로 높인 경우 필요한 요청만 재현하고 문제 해결 후에는 평소 수준으로 복원하세요. 접속 대상이 기록에 계속 저장되지 않도록 주의해야 합니다.

되돌릴 때는 새로 추가한 트래픽 가로채기와 사용자 지정 항목을 먼저 비활성화하고, 기존 라우팅과 DNS를 복원한 다음 검증된 서버를 다시 선택해 새 연결을 만드세요. 시스템 프록시 포트를 수정했다면 함께 복원해야 합니다. 이번 변경 사항을 ‘목적, 변경 내용, 검증, 롤백’ 네 가지로 기록하면 출처를 알 수 없는 큰 설정 파일을 보관하는 것보다 관리하기 쉽습니다. 처음 설정할 때는 빠른 시작 가이드를 따르고, 구체적인 증상은 문제 해결에서 계속 확인하세요.