Self-hosted IP judge service for proxy validation and network diagnostics.
IP Judge returns the client address observed by the service and a small, explicit set of diagnostic data. Proxy Checker uses judge nodes in different regions to verify whether a proxy is reachable and whether it changes or leaks the originating address. Status: foundation planning. There is no production release yet. The v2 backlog targets a Go service, while issue #1 contains an earlier PHP proposal; the runtime decision must be resolved before implementation.
Client or Proxy Checker
|
v
HTTP API (/ip, /json, /headers, /health)
|
v
Trusted-proxy resolution -> optional Geo/ASN enrichment
|
v
Sanitized judge response
The shared message and API shapes are owned by proxy-contracts.
Planned capabilities:
- GET /ip for a plain IP response
- GET /json for a versioned JSON response
- GET /headers for sanitized proxy-header diagnostics
- GET /health for liveness checks
- Trusted proxy-chain handling for Forwarded and X-Forwarded-For
- Optional country, ASN, and ISP enrichment
- Prometheus request, error, and latency metrics
No runnable release is available yet. Clone the repository to review the specifications and follow the v0.1 issues for the initial implementation.
git clone https://github.com/ichinya/ip-judge.git
cd ip-judgeA production container image is planned for v0.1 where applicable. Until an image and digest are published, there is no supported container invocation.
Configuration will be environment-based. Forwarding headers must only be trusted when the direct peer belongs to an explicitly configured trusted proxy range.
| Variable | Purpose |
|---|---|
HTTP_ADDR |
Listen address for the HTTP server |
TRUSTED_PROXY_CIDRS |
Comma-separated trusted reverse-proxy ranges |
ENRICHMENT_ENABLED |
Enable optional Geo/ASN enrichment |
GEO_DATABASE_PATH |
Path to an optional local enrichment database |
LOG_LEVEL |
Structured log level |
Names and defaults are proposed and may change before v0.1. Never commit production secrets.
Target runtime: Go.
- Choose an open roadmap issue and confirm its acceptance criteria.
- Keep contracts and examples versioned; coordinate cross-repository changes explicitly.
- Add tests for behavior changes and update documentation in the same pull request.
- Run the repository-specific checks documented by the implementation once they exist.
See CONTRIBUTING.md for the common workflow and SECURITY.md for private vulnerability reporting.
- v0.1 Foundation: repository structure, documentation, Docker/CI foundations, and base contracts.
- v0.2 MVP: collector -> scheduler -> MQ -> checker -> judge -> database -> site working cycle.
- v1.0 Production: multi-region judges, scoring, API, billing, monitoring, and high availability.
Track delivery in the repository milestones and issues.
MIT License