-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This wiki serves as the technical documentation for the v3.23-fix fork of the UrNetwork Connect provider. This fork is specifically optimized for professional providers operating in high-volume networking environments.
Detailed technical rationale for the experimental tuning profiles, including contract scaling, signaling timeouts, and TCP window management.
How to use the built-in monitoring tools (vnStat, stats script) and interpret the high-signal logs.
Common error codes and how to resolve them, specifically focusing on signaling timeouts and resource exhaustion.
Best practices for Docker security, multi-arch builds, and system-level networking tweaks.
Directory layout and purpose of every package, binary, and workflow file in the repository.
How to add and remove proxies from a running provider without restarting, and how the trigger-file mechanism works.
How the GitHub Actions workflows are structured, how to cut a release tag, and what each workflow does.
8. Installation
Install the provider on Linux, macOS, or Windows (native binary or Docker), including the one-line install.fullbars.xyz installer.
Environment variables, runtime flags, and configuration reference for the provider.
Production Docker deployment guide: images, env vars, idle-update, and upgrade behavior. Docker-only operators manage their containers with the host-side urnet-docker tool (curl -fSsL .../install-urnet-docker.sh | sh).
11. Hub Setup
Run your own hub: initialization, linking, trusted-proxy XFF configuration, and dashboard.
12. Hub Dashboard
The hub dashboard UI: summary cards, charts, proxy management, and rate limiting.
13. Proxy Management
Managing proxies: file lists, add/remove, hot-reload, health, and traffic views.
Feed the provider a live proxy-list URL instead of (or alongside) a static file — fetch cadence, cleanup scope, and runtime proxy add-source/remove-source.
Running multiple provider containers per host and how to scale out.
How the fork's contract and throughput tuning amplifies billable traffic.
What provider, hub, and tool log lines mean and how to read them.
18. urnet-tools (Go)
The provider-aware Go rewrite of the fleet ops tool: discovery, targeting, safety model, and the multi-provider migration guide.
How the provider probes, verifies, and grades proxies before admitting them: the three-stage probe, MITM detection, the 150-endpoint target table, and the auth admission gate.
The layered packet-inspection policy: CFAA endpoint reputation, DMCA BitTorrent detection, and the web-standard matcher.
The host-side CLI for managing provider containers: providers, exec, restart, logs, update.
Best for testing or low-volume environments.
docker run -d \
--name=urnetwork \
--pull=always \
--restart=unless-stopped \
--cap-add=NET_ADMIN \
--cap-add=NET_RAW \
--sysctl net.ipv4.ip_forward=1 \
-e BUILD='jwt' \
-v urnetwork_config:/root/.urnetwork \
-v /path/to/your/proxy.txt:/app/proxy.txt \
ghcr.io/full-bars/urnetwork-3.23-fix:latest YOUR_AUTH_CODE_HERERecommended for production providers managing large proxy lists.
docker run -d \
--name=urnetwork \
--pull=always \
--restart=unless-stopped \
--log-driver=json-file \
--log-opt max-size=100m \
--log-opt max-file=3 \
--cap-add=NET_ADMIN \
--cap-add=NET_RAW \
--sysctl net.ipv4.ip_forward=1 \
-e BUILD='jwt' \
-e ENABLE_VNSTAT=true \
-v urnetwork_config:/root/.urnetwork \
-v vnstat_data:/var/lib/vnstat \
-v /path/to/your/proxy.txt:/app/proxy.txt \
-p 8080:8080 \
ghcr.io/full-bars/urnetwork-3.23-fix:latest YOUR_AUTH_CODE_HERE-
Log Management: The high-volume command includes
max-size=100mto prevent logs from consuming your entire disk. This is highly recommended. -
CPU Limiting: On a low-end VPS,
--cpus=1.0caps the container's CPU usage so the provider can't monopolize the host — useful for keeping other services responsive. It does not make the provider more stable: if the cap is too tight for your proxy count, it can starve the signaling layer and cause contract timeouts. Only set a cap you've measured the provider staying under.
Important
If you are managing 1,000+ proxies, do NOT set a CPU limit. Strict CPU capping at high volume is a primary cause of signaling timeouts and connection drops.
If you are seeing signaling timeouts or connection instability even after applying the tuning profiles, please check the Performance Tuning troubleshooting section.