궁금한 점을 알기 쉽게 해결하세요.

클라이언트 가져오기, 업데이트 및 테스트를 위해 스토리지에 guiLogs를 사용하세요. 파일 로깅이 활성화된 경우 코어 연결 또는 코어 파일에 대한 정보 패널을 검사합니다.

OS, 클라이언트/코어 버전, 시간 및 최소 재생 단계를 기록합니다. 자격 증명 및 개인 주소를 수정한 후 관련 간격만 공유하세요. 새로운 출력을 구별하기 위해 재시도하기 전에 시간을 표시하십시오.

별도의 휴대용 폴더를 사용하면 독립적인 구성을 유지할 수 있습니다. 고유한 혼합 포트를 사용하고 관련 오프셋 +1, +2, +3, +4, +5 및 +21 간의 충돌을 피하십시오.

시스템 프록시 또는 TUN 경로를 위해 경쟁하는 여러 인스턴스를 피하세요. 앱 프록시 포트를 명시적으로 할당하고 시스템 설정 소유자 한 명을 선택합니다.

포함된 7.25.6 릴리스에는 다운로드 페이지에 x86이라는 라벨이 붙은 Windows-86 ZIPs가 있습니다. 32비트 패키지 구축에 대한 이전 FAQ 참고 사항은 기록입니다.

OS와 코어 호환성도 확인해보세요. 32비트 시스템은 64비트 바이너리를 실행할 수 없습니다. GUI만 변경해도 일치하지 않는 코어가 수정되지 않습니다.

윈도우 다운로드

현재 패키지에는 Windows 10 이상이 필요합니다. Windows 7은 이 다운로드 경로에서 지원되지 않습니다. 호환성에는 하나의 런타임이 아닌 .NET, UI 프레임워크 및 Go 기반 코어가 포함됩니다.

지원되는 OS에서 일치하는 패키지를 사용하세요. 레거시 환경을 유지 관리하는 경우 최신 코어를 혼합하는 대신 클라이언트/코어 쌍을 함께 평가하십시오.

시스템 정보에서 ARM64를 확인하고 전체 일치 패키지를 추출합니다. GUI가 열렸지만 코어에 장애가 발생한 경우 코어 바이너리 아키텍처 및 프로토콜 지원을 확인하세요.

과거 장치 논의가 모든 ARM 장치의 작동을 보장하지는 않습니다. OS 빌드, 프로세서 및 정확한 오류를 기록하여 에뮬레이션, 아키텍처 및 구성 문제를 분리합니다.

Windows 시스템 프록시 인터페이스는 주로 HTTP 프록시 설정을 구성합니다. 클라이언트의 혼합 수신기는 HTTP 및 SOCKS5를 둘 다 표시하지 않고 모두 허용할 수 있습니다.

SOCKS5가 필요한 앱은 자체 설정에서 127.0.0.1과 실제 혼합 포트를 사용할 수 있습니다. HTTP 프록시를 통한 HTTPS는 일반적으로 CONNECT를 사용합니다. 이는 HTTPS 콘텐츠를 일반 텍스트로 변환하지 않습니다.

코어 시작을 확인하고 guiLogs에서 프록시 스크립트 오류를 검사합니다. macOS 설정은 네트워크 서비스별로 적용됩니다. 특히 네트워크를 전환한 후에는 Wi-Fi와 이더넷이 다를 수 있습니다.

시스템 설정 → 네트워크 → 활성 서비스 → 세부 정보 → 프록시를 확인하세요. 수동 설정의 경우 127.0.0.1과 실제 혼합 포트를 사용한 다음 완료되면 해당 수동 항목을 비활성화합니다. 사용자 정의 프로필은 자체 수신기 포트를 사용할 수 있습니다.

핫스팟만으로는 다른 장치를 프록시할 수 없습니다. LAN 액세스를 활성화하고, 실제 LAN 수신기를 확인하고, 호스트 방화벽을 통해 신뢰할 수 있는 로컬 장치를 허용합니다.

다른 장치에서는 127.0.0.1이 아닌 컴퓨터의 LAN IP와 LAN 포트를 사용하십시오. 게스트 네트워크/AP 격리로 인해 액세스가 차단될 수 있습니다. 통제된 네트워크에 대한 노출을 제한하고 사용하지 않는 청취자를 비활성화합니다.

커뮤니티 레시피는 일치하는 GEO 데이터가 설치된 프록시 캐치올 앞에 geosite:steam@cn 및 domain:steamserver.net에 대한 직접 도메인 규칙을 추가합니다.

이는 모든 지역/CDN의 적용 범위를 보장하지 않습니다. 다운로드를 다시 시작하고 실제 목적지/아웃바운드를 검사하세요. 필요한 경우 관찰된 다운로드 도메인을 추가하고 스토어/커뮤니티 트래픽을 다운로드와 구별합니다. 결과는 코어와 데이터세트에 따라 다를 수 있습니다.

일반적인 네트워킹, 프로필 유효성, 핵심 시작 및 앱이 로컬 리스너에 도달하는지 여부를 확인한 다음 라우팅 및 DNS를 확인하세요. 디버그가 활성화된 상태에서 한 번 재현하고 첫 번째 관련 오류를 식별합니다.

1. 연결이 거부되었습니다. 서비스가 로컬/원격 포트에서 수신하는지 확인하세요.
2. 시간 초과: 직접 액세스와 알려진 작업 프로필을 비교합니다.
3. 인증서/TLS: 시계, SNI, 트러스트 체인 및 핀을 확인하세요.
4. 알 수 없는 필드/지원되지 않음: 클라이언트/코어 버전 및 템플릿을 확인하세요.
5. 핵심 요청 로그 없음: 아웃바운드 규칙을 변경하기 전에 앱 프록시 또는 TUN 항목을 확인하세요.

PAC는 애플리케이션에서 실행됩니다. DIRECT 요청은 코어 라우팅 및 로그를 우회합니다. 자동 프록시는 일반적으로 요청을 먼저 코어로 보냅니다.

코어 라우팅을 검사하기 전에 앱이 실제로 사용하는 입력 모드, PAC 캐싱 및 항목 우회를 확인하세요.

시스템 프록시 모드

노드, 확인자, 대상 호스트 이름을 별도로 확인하세요. 호스트 이름 기반 확인자는 순환 종속성을 피하기 위해 연결 가능한 IP 기반 부트스트랩이 필요합니다.

브라우저에서 관리하는 암호화된 DNS, 캐시, 호스트 및 FakeIP가 결과에 영향을 미칠 수 있습니다. 기본 DNS로 기준선을 설정하고 사용자 정의 옵션을 개별적으로 활성화합니다. Xray 라우팅 확인은 아웃바운드 확인과 다릅니다.

DNS 참조

정확한 호스트 이름, 브라우저 오류 및 시간을 기록한 다음 직접 동작과 프록시 동작을 비교하십시오. 초기 직접/차단 규칙을 검사하고 항목을 우회하며 DNS 답변을 확인하세요.

사이트에서 출구 IP 주소, 지역 또는 계정을 제한할 수 있습니다. 정상 작동이 확인된 구성과 비교하면 원인을 파악하는 데 도움이 되지만, 모든 Bing 문제를 해결하는 방법은 없습니다. 인증서 검증과 관련 없는 규칙은 그대로 유지하세요.

오류를 기록하고 유틸리티 권한을 확인한 다음 UWP 앱이 설치되었는지 확인하세요. 축소/LTSC 설치는 애플리케이션 구성 요소에 따라 다를 수 있으므로 대상을 열거할 수 있는지 확인하세요.

루프백 인증을 방화벽 비활성화로 대체하지 마십시오. 일반 브라우저와 비교하여 코어/프록시 오류로부터 앱 샌드박스를 격리하세요.

프로젝트 토론에는 혼잡 제어 사례는 물론 포트 충돌 및 시계 문제도 포함됩니다. OS 버전만으로는 원인을 알 수 없습니다. 업데이트, 시간, 로그 및 포트를 확인한 다음 시스템 프록시를 TUN와 비교하세요.

아래 읽기 전용 명령은 현재 TCP 설정을 표시합니다. 특정 네트워크 스택 옵션을 격리하고 이전 값을 기록한 후에만 변경하십시오.

Windows · PowerShell · 읽기 전용복사

Get-NetTCPSetting | Select-Object SettingName,CongestionProvider

TUN를 끄고 일반 시스템 프록시를 통해 동일한 프로필을 확인하세요. 프로필/코어 오류를 먼저 수정하세요. TUN 전용 문제의 경우 권한, 인터페이스 생성, 경로, DNS 및 경쟁 VPN/가상 어댑터를 확인하세요.

기본값, 적절한 스택 및 더 작은 MTU를 한 번에 하나씩 변경해 보십시오. 로컬 리소스에 대한 제외 CIDRs를 확인하세요. 로컬 ICMP 응답은 원격 프록시 연결을 증명하지 않습니다.

TUN 설정

이는 테스트 구성을 시작하는 데 실패했으며 모든 서버에 연결할 수 없다는 증거는 아닙니다. 첫 번째 디버그 오류, 바이너리 아키텍처/실행 권한, 지원되는 필드 및 리스너/테스트 포트 충돌을 검사합니다.

테스트에서는 기본 포트 +21을 사용하며 대규모 배치에서는 리소스를 소비합니다. Windows 가상화에서는 포트 범위를 예약할 수 있습니다. 하나의 프로필, 더 작은 배치 및 충돌하지 않는 기본 포트를 비교하십시오. 시스템 예약을 무분별하게 삭제하지 마십시오.

지원은 게임 트래픽, TCP/UDP, 코어 및 서버에 따라 다릅니다. 많은 게임은 시스템 HTTP 프록시를 무시하고 앱별 설정 또는 TUN가 필요합니다.

프록시는 낮은 대기 시간을 보장하지 않습니다. 거리, 손실 및 추가 홉으로 인해 상황이 악화될 수 있습니다. 브라우저 속도 테스트에 의존하기보다는 동일한 게임 시나리오를 비교해 보세요.

Windows에서는 저장소에 있는 NotifyIcon1.ico부터 NotifyIcon4.ico까지 시스템 프록시 상태에 대한 트레이 아이콘을 제공합니다. 기존 파일을 백업하고 유효한 ICOs를 제공한 후 다시 시작하여 검사하세요.

규칙 세트 PNG 아이콘은 이러한 상태 아이콘보다 우선하므로 아이콘이 변경되지 않는다고 해서 반드시 프록시 모드가 변경되지 않았다는 의미는 아닙니다.

종료하면 정리가 완료되지 않을 수 있습니다. 다음 부팅 시 오래된 localhost 프록시로 인해 클라이언트가 중지된 동안 애플리케이션이 연결되지 않을 수 있습니다.

시스템 프록시를 다시 열고 지우거나 OS를 통해 오래된 수동/PAC 설정을 제거하세요. 그만두기 전에 정리하면 남은 음식이 줄어듭니다.

이러한 경로는 작동할 수 있지만 외부 코어, 스크립트, 권한 또는 동기화 도구로 인해 제한이 적용될 수 있습니다. 짧고 쓰기 가능한 로컬 경로에서 완전한 휴대용 폴더를 사용하는 것과 비교해 보세요.

명령에서 경로를 공백으로 인용하세요. 동반 파일을 보관하고 권한 실패와 인코딩 문제를 구별하세요.

클라이언트는 인바운드, 로그, 라우팅 및 아웃바운드를 조합한 다음 기본/사용자 지정 DNS, 호스트 및 노드 확인을 적용합니다. 전체 템플릿은 생성된 프록시 아웃바운드를 통합하고 다른 곳의 일반 설정을 재정의할 수 있습니다.

코어는 최종 결과를 실행합니다. UI 설정이 효과가 없는 것으로 나타나면 동일한 스위치를 반복적으로 변경하는 대신 전체 템플릿, 사용자 정의 파일 및 명시적인 Core 할당을 검사하십시오.