21 lines
1.7 KiB
Markdown
21 lines
1.7 KiB
Markdown
# 3proxy Official Notes
|
|
|
|
Updated: 2026-04-01
|
|
|
|
Sources:
|
|
|
|
- [3proxy configuration reference](https://github.com/3proxy/3proxy/wiki/3proxy.cfg)
|
|
- [3proxy how-to documentation](https://3proxy.org/doc/howtoe.html)
|
|
- [3proxy man page](https://3proxy.org/doc/man8/3proxy.8.html)
|
|
|
|
## Relevant findings
|
|
|
|
1. `3proxy.cfg` is an executable-style script where command order matters, so the panel should generate config deterministically and preserve service ordering.
|
|
2. Services such as `socks`, `proxy`, `admin`, `dnspr`, `tcppm`, and `udppm` are started directly from config lines, making a structured config editor practical.
|
|
3. User auth is officially handled through `auth strong` and `users username:pwtype:password`; this maps cleanly to a user-management UI.
|
|
4. ACLs are reset with `flush`, which means a visual config builder should make service-level ACL boundaries explicit.
|
|
5. Traffic limits are handled through `counter`, `countin`, `countout`, and `countall`, with optional text reports generated from the counter file. This is the right base for quota support and usage reporting.
|
|
6. Built-in logging supports custom `logformat`, including `%U`, `%I`, `%O`, `%n`, `%E`, and timestamps. That provides a future path for richer analytics if counters are not enough.
|
|
7. `monitor <filename>` can trigger config reload on file changes, and the man page documents signal-based reload behavior, so the runtime layer should favor graceful reload over brute-force restarts where possible.
|
|
8. The `admin` service exists, but it should not be the primary control surface for this project. The panel should own config generation and use admin endpoints only when they provide safe, official visibility.
|