Proxy setup
Each slot requires its own proxy for X API requests. The parser accepts 12 different format variants. Residential proxies are recommended.
Supported formats
The proxy parser accepts all of these variants:
| # | Format | Example |
|---|---|---|
| 1 | host:port | proxy.example.com:1080 |
| 2 | host:port:user:pass | proxy.example.com:1080:myuser:mypass |
| 3 | user:pass@host:port | myuser:[email protected]:1080 |
| 4 | host:port@user:pass | proxy.example.com:1080@myuser:mypass |
| 5–8 | Same 4 formats with http:// prefix | http://myuser:[email protected]:1080 |
| 9–12 | Same 4 formats with socks5:// prefix | socks5://proxy.example.com:1080 |
The https:// prefix is also accepted.
How the parser works
The parser automatically detects the format you paste in. It recognizes protocol prefixes (http://, socks5://), @-separated auth, and colon-separated fields. The output is always normalized internally, so any of the supported formats above will work.
Proxy types
- SOCKS5 (default) — recommended for X API requests. Most residential proxy providers support SOCKS5.
- HTTP/HTTPS — also supported. The protocol extracted from the input (if present) is preserved as the proxy type.
The proxy type is stored per slot and passed to all module workers.
Proxy encryption
Proxy strings are encrypted at rest using the same AES-256-GCM scheme as auth tokens (see Security). The encrypted value is stored; decryption happens at runtime when modules need the proxy.
Tips
- Use residential proxies to minimize detection risk. Datacenter IPs are more likely to trigger X's anti-automation measures.
- Each slot should have a unique proxy. Sharing proxies across multiple X accounts increases the chance of correlated suspensions.
- If your proxy provider gives you a URL format, paste it directly — the parser handles most variations.
- Validation rejects strings that don't parse to a valid host + port (1–65535).