3proxy의 HTTP 및 SOCKS 서비스 모두에서 로그인 요구

사용자를 정의하는 것만으로는 3proxy 로그인 구성이 완성되지 않습니다. 서비스에는 인증 방식과 이를 사용하는 접근 규칙도 필요합니다. 구성이 처리되는 동안 서비스 설정이 적용되므로 순서가 중요합니다.

두 서비스에 대한 로컬 전용 예시는 다음과 같습니다.

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

구성 참조에서는 users, auth strong 및 서비스 명령을 설명합니다. CL은 이 예시 비밀번호를 평문으로 저장합니다. 파일을 보호하고 배포 환경에 맞는 지원되는 자격 증명 저장 형식을 선택하십시오.

클라이언트에는 올바른 로그인 교환이 필요합니다

HTTP 서비스는 HTTP 프록시 인증을 기대합니다. SOCKS 서비스에는 SOCKS5 사용자 이름과 비밀번호 인증을 지원하는 클라이언트가 필요합니다. SOCKS4 클라이언트는 같은 수신 포트에 도달한다는 이유만으로 그 교환을 제공할 수 없습니다.

strong이라는 단어는 인증 모드의 이름이며 암호화된 전송을 보장하지 않습니다. 필요할 때 클라이언트에서 프록시까지의 구간을 보호하십시오. 목적지까지의 HTTPS와 프록시까지의 암호화는 별개의 결정으로 남습니다.

루프백 바인딩은 이 예시를 로컬 접근으로 제한합니다. 원격 클라이언트의 경우 의도한 수신기와 네트워크 정책을 명시적으로 선택하십시오. 공용 와일드카드 수신기는 로그인 동작을 확인하는 것을 대체하지 않습니다.

한 서비스는 자격 증명을 요구하고 다른 서비스는 요구하지 않는다면, 각 서비스 명령 이전의 설정, flush 이후의 규칙, 인증 캐시를 검사하십시오. 비밀번호를 바꾸는 것으로는 잘못된 정책 아래 시작된 서비스를 고칠 수 없습니다. 마찬가지로 데몬의 운영 체제 계정을 바꾸는 것은 프록시 사용자를 만들지 않습니다.