정말 비난받아 마땅한 사업이다. 검증되고 승인된 제휴사만 이용한다고 하지만, 주거용 프록시의 합법적인 용도는 단 하나도 떠오르지 않음. 실제로 그런 용도가 있나?

주거용 프록시 규제에는 신중해야 한다. 이를 겨냥해 규제를 만들면 주거용 프록시 봇넷 외에도 훨씬 많은 대상이 영향을 받게 됨

또 다른 피해자는 링크 검사기다. 사이트에 죽은 링크가 있는지 확인하기가 상당히 어려워짐
시간이 있다면 콘텐츠가 여전히 살아 있는지 확인하는 데 Common Crawl 프로젝트를 활용해볼 것 같음

채팅 앱이 발신자 측에서 생성하는 링크 미리보기도 피해를 본다. XMPP 클라이언트인 gajim에 이 기능을 기여해 기뻤지만, 실제로는 링크 미리보기 요청이 너무 자주 “사람인지 확인 중” 화면에 막혀서 우울할 정도임

결국 GitHub 저장소의 이력 나열처럼 비용이 큰 작업은 모두 인증 장벽 뒤로 숨고, 나머지는 정적으로 만들어 CDN으로 제공하게 될 것임

중앙화와 정부 감시 등이 우려되므로 CDN은 최후의 수단이어야 하며, 먼저 서버 자체에서 더 많은 성능을 끌어내야 한다고 봄
애플리케이션 수준에서는 더 많은 콘텐츠를 정적으로 만들고, 데이터베이스 질의를 줄이며, 캐시를 활용하는 것이 분명 도움이 된다. 오랫동안 성능을 크게 걱정하지 않아도 되는 사치를 누렸지만 이제는 작은 사이트에서도 더 신경 써야 하며, 어디서나 Cloudflare의 “브라우저 확인 중”을 보는 것보다는 훨씬 낫다
작은 VPS에서 Apache가 요청마다 별도 프로세스를 포크하는 전통적인 방식 때문에 문제가 생긴 적이 있다. LAMP 서버를 만지며 자라 Apache가 친숙하고 편하지만, 장비를 가장 효율적으로 활용하지는 못하며 결국 그 점이 더 중요하다. 실증 자료는 없지만 Caddy 같은 서버가 부하를 더 잘 견딜 것 같아 다음 서버 업그레이드 때 전환할 생각임

내 Forgejo 서버도 같은 상황이었다. 지속적인 악성 트래픽을 Anubis로 관리하려 했지만, 해당 트래픽에 맞춰 설정을 조정하는 법을 완전히 이해하지 못했고 느린 인증 과제를 직접 마주하는 것도 마음에 들지 않았다
fail2ban도 사용해봤지만 규모가 커지자 제대로 대응하지 못했다. 결국 블로그 글에 정리한 보안 규칙으로 Cloudflare가 처리하게 했다. Cloudflare에 장기간 의존하기는 꺼려졌지만, 글 아래쪽의 CPU 사용량 그래프를 보고 마음을 바꿈

반면 Git 저장소와 크롤러의 궁합은 극도로 나쁘다. 동적으로 생성되는 링크가 조합 폭발을 일으켜 임시변통식 크롤러 함정을 만들기 때문에, 조금이라도 제대로 된 크롤러라면 경로에 긴 16진수 문자열이 들어간 URL을 적극적으로 피함
Git 호스트에 엄청난 비용을 유발하는데도, 의외로 많은 호스트가 저장소 내부까지 깊게 크롤링하지 못하도록 robots.txt를 설정하지 않음

“사이트를 방어하기 위해 취한 조치를 설명해 달라는 요청이 있었지만, 명백한 이유로 자세히 논의하고 싶지는 않다. 이 수준에서도 군비 경쟁이 벌어진다”는 대목이 마음 아프다
나도 이 싸움에서 꽤 성공했지만, 공유지의 비극 때문에 사용한 아주 단순한 대책을 공개하면 효과가 떨어진다. 정말 흥미로운 주제이고 독창적인 아이디어도 있어 블로그에 쓰고 싶지만 그럴 수 없어 안타까움