화이트리스트, 밴, 오피: 예상과 다르게 작동하는 서버 명령어들
화이트리스트는 이미 접속 중인 플레이어를 추방하지 않으며, /ban은 유용하려면 이유가 필요하고, 오피 레벨은 오피 목록보다 더 중요합니다. 서버 소유자를 당황하게 하는 세부 사항들을 알려드립니다.
관리 명령어는 간단해 보이고 대부분 그렇습니다. 하지만 구문만으로는 명확하지 않은 세 가지 동작 때문에 문제가 발생합니다.
화이트리스트는 이미 접속 중인 플레이어를 제거하지 않습니다
/whitelist on는 그 순간부터 목록을 적용하기 시작합니다. 이미 연결된 플레이어는 목록에 없더라도 연결 상태를 유지합니다. 이 간극을 메우는 명령어는 다음과 같습니다:
/whitelist reloadreload는 whitelist.json를 다시 읽고 또한 목록에 없는 접속 중인 플레이어를 추방합니다. 화이트리스트를 켜고 그냥 두는 것이 흔한 실수입니다.
두 가지 추가 세부 사항:
/whitelist add <name>는 Mojang API에 대해 이름을 확인하므로, 서버가 온라인 모드이고 연결되어 있어야 합니다. 오프라인 서버는 올바른 UUID로whitelist.json을 수동으로 편집해야 합니다.- 운영자는 기본적으로 화이트리스트를 우회합니다. 이것이 바로 자신의 계정으로는 화이트리스트가 작동하는지 증명할 수 없는 이유입니다. 두 번째 계정으로 테스트하세요.
/ban은 이유를 원하고, /ban-ip는 다른 목록입니다
/ban <player> [reason]
/ban-ip <address|player> [reason]이유는 선택 사항이지만, 생략하는 것은 실수입니다. 이는 차단된 플레이어가 보는 내용이며, 나중에 당신이 /banlist에서 이유를 기억하려고 읽는 내용입니다. 이유가 없으면 항목에는 "운영자에 의해 차단됨"이라고만 표시됩니다.
/ban 및 /ban-ip는 별도의 파일 (banned-players.json, banned-ips.json)에 기록합니다. 하나를 사면하는 것이 다른 하나를 지우지 않으며, 이것이 "사면된" 플레이어가 여전히 연결할 수 없는 일반적인 이유입니다. /pardon와 /pardon-ip을 모두 사용하세요.
오피 목록뿐만 아니라 오피 레벨도 중요합니다
/op는 기본적으로 레벨 4를 부여하며, 이는 /stop를 포함한 모든 접근 권한입니다. 네 가지 레벨은 실제이며 server.properties에서 op-permission-level을 통해 설정할 수 있습니다:
| 레벨 | 부여 권한 |
|---|---|
| 1 | 스폰 보호 우회 |
| 2 | 대부분의 치트 명령어, 명령 블록 |
| 3 | 플레이어 관리 — 킥, 밴, 오피 |
| 4 | /stop을 포함한 모든 권한 |
/kick 및 /ban이 필요한 모더레이터는 레벨 4가 아닌 레벨 3을 원합니다. 모더레이션을 돕는 모든 사람에게 레벨 4를 부여하는 것은 계정 침해로 서버가 초기화되는 방법입니다.
function-permission-level은 별개이며 데이터팩 함수가 실행될 수 있는 것을 제어합니다. 오피 레벨이 4인 동안 이를 2로 두는 것은 "내 함수가 아무것도 하지 않는다"는 불평의 흔한 원인입니다.
목록 명령어
/banlist players, /banlist ips 및 일반 /banlist는 모두 존재하며 서버 터미널에서 실행하면 채팅이 아닌 콘솔에 출력됩니다. /whitelist list는 이름만 표시하고 UUID는 표시하지 않습니다. 신원을 확인해야 할 때는 whitelist.json을 읽으세요.
서버 관리 명령어 빌더에서 밴, 밴-IP, 사면, 킥, 오피, 디오피, 화이트리스트를 한 양식으로 다루는 인수를 올바른 순서로 사용하여 이들 중 하나를 만드세요.