•  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
r172 vs r173
......
166166
167167
===== 해결방안 =====
168168
====== 사측이 임명한 관리자에게 권한을 부여 ======
169
유일하게 가능성이 매우 낮지만 가장 높은 해결방안이다. 사측 관리자가 임명한 관리자 중 다중계정만 검사할 수 있는 권한만 부여하는 것이다. 해당 관리자는 이용자의 ID와 IP 그리고 UserAgent등을 조회할 수 있는 권한을 가지게 되며, 양식에 맞게 보고서를 작성하여 게시토록 하고, 필요시 오리실험도 할 수 있으며, 역시 어떠한 근거로 오리실험을 하였는지에 대해 기록하도록 하면 되겠지만... 사측에서 그러한 권한을 부여해 줄지는 미지수이다.[* 그 증거로 일반 유저출신 관리자들은 "사측으로 이관합니다."라는 말을 반복한다.]
170
171
169
유일하게 가능성이 매우 낮지만 가장 높은 해결방안이다. 사측 관리자가 임명한 관리자 중 다중계정만 검사할 수 있는 권한만 부여하는 것이다. 해당 관리자는 이용자의 ID와 IP 그리고 UserAgent등을 조회할 수 있는 권한을 가지게 되며, 양식에 맞게 보고서를 작성하여 게시토록 하고, 필요시 오리실험도 할 수 있으며, 역시 어떠한 근거로 오리실험을 하였는지에 대해 기록하도록 하면 되겠지만... 사측에서 그러한 권한을 부여해 줄지는 미지수이다.
172170
===== 결론: 묻지마 차단 =====
173171
174172
점차 정상적인 IP마저도 프록시랍시고 차단하는 경우가 많아졌다. 만약 집이 아닌 다른 곳에서 계정을 생성하거나 혹은 이사가기 직전에 새 IP에서 계정을 생성하고 모바일에서만 주구장창 이용하면 나무위키의 사측 관리자가 가입당시 사용했던 IP를 프록시랍시고 차단하는 경우도 있다.
......