고객 지원 문의

이메일로 답장드리며, 보통 이틀 안에 회신합니다.

Google reCAPTCHA가 이 제출을 악용 여부에 대해 확인하며, 이 과정에서 데이터가 Google로 전송됩니다. 스크립트는 이 양식을 열 때만 불러옵니다.

← 전체 글

What stats2.gif actually is

There is a file in this project's image folder called stats2.gif. It is 366 bytes, dated March 2018, and it appears in exactly zero lines of source code. On 23 August 2026 it was served 2,735 times with a 200, from 145 different websites — and over the full rotation of the access log, from 858.

A file nobody references, fetched thousands of times a day from hundreds of strangers' pages. The obvious reading: an old embed that people never replaced, quietly serving a static image where a counter used to be. Static files bypass PHP entirely. Nothing that reaches Apache directly can count anything.

So we wrote a tool. It reads every referring page out of the log, fetches each one through the same checker the site already uses for embed diagnostics — with its SSRF guards, because those addresses come from a log and not from us — and looks for whether anything on the page actually counts.

All 858 pages

already counting (a working embed alongside)501
not reachable at all288
badge present, no counter number in the source69
only the old badge, nothing counting0
already counting501unreachable288icon, no number69the case we looked for: 0

Not one. Seventy-five minutes of fetching, and the answer was no.

The measurement that takes one second

stats2.gif is 13 by 14 pixels.

That is not a counter and not a badge with a number on it. It is the small statistics icon — the same thing design 981 in the current gallery recreates, and that design's own source comment describes its ancestor precisely: no visible count, just a small mark that opens the statistics when clicked. It was never supposed to count. On those pages, something else always did.

The file is not broken either. It answers 200 with a Last-Modified from 2018 and a year of cache lifetime. It does its job.

One call to getimagesize() settles that whole line of inquiry in a second. Here the question was "why is this file fetched so often", the assumed answer was "because it is a broken counter", and everything after it rested on the assumption rather than on the file — which is what makes the one-second check worth running first.

The one thing that really is broken

Out of all of it, the log showed a single genuine defect: one address, requested ten times a day, all 410, where an entire embed snippet had ended up inside the link's href. Somebody pasted the code into a field that escapes HTML. Their counter is alive and counting — only their own link to their own statistics leads nowhere.

The tool stays, without its write path. The question was legitimate; the answer is no; and both are worth keeping so nobody has to ask it by hand again.

광고