microwarp-cloudflare-proxy
```markdown
What this skill does
```markdown
---
name: microwarp-cloudflare-proxy
description: Ultra-lightweight Cloudflare WARP SOCKS5 proxy in Docker using kernel-level WireGuard and microsocks, consuming under 800KB RAM
triggers:
- set up cloudflare warp proxy docker
- lightweight warp socks5 container
- microwarp setup and configuration
- replace caomingjun warp with microwarp
- cloudflare warp wireguard docker low memory
- warp proxy with authentication docker
- bypass cloudflare warp regional blocks
- warp socks5 proxy under 1mb ram
---
# MicroWARP Cloudflare Proxy
> Skill by [ara.so](https://ara.so) — Daily 2026 Skills collection.
MicroWARP is an ultra-lightweight Cloudflare WARP SOCKS5 proxy that runs inside Docker using Linux kernel-level WireGuard (`wg0`) and a pure-C `microsocks` server. It uses **~800KB RAM** and a 9MB image — compared to 150MB RAM and 201MB image for `caomingjun/warp`.
## Architecture
- **WireGuard kernel module** (`wg0`): handles WARP tunnel at kernel level, near-zero CPU
- **microsocks**: pure C SOCKS5 server, no Go/Rust overhead
- **Auto-registration**: fetches free WARP credentials from Cloudflare API on first run
- **Persistent volume**: saves WireGuard config to avoid re-registration on restart
## Installation
### Docker Compose (recommended)
```yaml
# docker-compose.yml
version: '3.8'
services:
microwarp:
image: ghcr.io/ccbkkb/microwarp:latest
container_name: microwarp
restart: always
ports:
- "1080:1080"
cap_add:
- NET_ADMIN
- SYS_MODULE
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
volumes:
- warp-data:/etc/wireguard
volumes:
warp-data:
```
```bash
docker compose up -d
docker compose logs -f # watch first-run registration
```
### Docker Run (one-liner)
```bash
docker run -d \
--name microwarp \
--restart always \
-p 1080:1080 \
--cap-add NET_ADMIN \
--cap-add SYS_MODULE \
--sysctl net.ipv4.conf.all.src_valid_mark=1 \
-v warp-data:/etc/wireguard \
ghcr.io/ccbkkb/microwarp:latest
```
## Environment Variables
| Variable | Default | Description |
|---|---|---|
| `BIND_ADDR` | `0.0.0.0` | SOCKS5 listen address |
| `BIND_PORT` | `1080` | SOCKS5 listen port |
| `SOCKS_USER` | *(empty)* | Auth username (empty = no auth) |
| `SOCKS_PASS` | *(empty)* | Auth password |
| `ENDPOINT_IP` | *(auto)* | Custom WARP endpoint IP:port (bypass DPI) |
## Configuration Examples
### With SOCKS5 Authentication
```yaml
version: '3.8'
services:
microwarp:
image: ghcr.io/ccbkkb/microwarp:latest
container_name: microwarp
restart: always
ports:
- "1080:1080"
cap_add:
- NET_ADMIN
- SYS_MODULE
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
environment:
- SOCKS_USER=${WARP_USER}
- SOCKS_PASS=${WARP_PASS}
volumes:
- warp-data:/etc/wireguard
volumes:
warp-data:
```
### Custom Port + Auth
```yaml
environment:
- BIND_ADDR=127.0.0.1 # localhost only
- BIND_PORT=9050
- SOCKS_USER=${WARP_USER}
- SOCKS_PASS=${WARP_PASS}
```
### Bypass Regional Blocks (HK/US DPI)
If Cloudflare's `reserved` bytes verification blocks your region, inject a clean endpoint IP:
```yaml
environment:
- ENDPOINT_IP=162.159.193.10:2408
```
Scan for clean endpoints using tools like `warp-endpoint-scanner` and inject the best one.
### Localhost-Only Binding (secure setup)
```yaml
ports:
- "127.0.0.1:1080:1080" # only accessible from host
environment:
- BIND_ADDR=0.0.0.0 # container listens on all interfaces
```
## Usage Patterns
### Test the proxy
```bash
# Basic connectivity test
curl --socks5 127.0.0.1:1080 https://cloudflare.com/cdn-cgi/trace
# With authentication
curl --socks5-hostname 127.0.0.1:1080 \
--proxy-user "${WARP_USER}:${WARP_PASS}" \
https://cloudflare.com/cdn-cgi/trace
# Check your IP via WARP
curl --socks5 127.0.0.1:1080 https://ipinfo.io/json
```
### Use with Python (requests)
```python
import requests
proxies = {
"http": "socks5://127.0.0.1:1080",
"https": "socks5://127.0.0.1:1080",
}
# With auth
proxies_auth = {
"http": "socks5://user:[email protected]:1080",
"https": "socks5://user:[email protected]:1080",
}
resp = requests.get("https://ipinfo.io/json", proxies=proxies)
print(resp.json())
```
### Use with Node.js
```javascript
import { SocksProxyAgent } from 'socks-proxy-agent';
import fetch from 'node-fetch';
const agent = new SocksProxyAgent('socks5://127.0.0.1:1080');
// With auth: 'socks5://user:[email protected]:1080'
const res = await fetch('https://ipinfo.io/json', { agent });
console.log(await res.json());
```
### Convert to HTTP Proxy with gost
MicroWARP provides SOCKS5 only. Chain with `gost` for HTTP:
```bash
# Install gost
curl -fsSL https://github.com/go-gost/gost/releases/latest/download/gost_linux_amd64.tar.gz | tar xz
# Chain: HTTP :8081 → SOCKS5 microwarp :1080
# IMPORTANT: use socks5:// NOT socks5h:// to resolve DNS locally
nohup ./gost \
-F "socks5://${WARP_USER}:${WARP_PASS}@127.0.0.1:1080" \
-L "http://:8081" \
> /dev/null 2>&1 &
```
> ⚠️ Always use `socks5://` not `socks5h://` — `socks5h` delegates DNS to the proxy, which can deadlock during WireGuard UDP handshake cold start causing `503` errors.
### Multi-instance setup (different ports)
```yaml
version: '3.8'
services:
warp-1:
image: ghcr.io/ccbkkb/microwarp:latest
ports: ["1080:1080"]
cap_add: [NET_ADMIN, SYS_MODULE]
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
volumes:
- warp-data-1:/etc/wireguard
warp-2:
image: ghcr.io/ccbkkb/microwarp:latest
ports: ["1081:1080"]
cap_add: [NET_ADMIN, SYS_MODULE]
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
volumes:
- warp-data-2:/etc/wireguard
volumes:
warp-data-1:
warp-data-2:
```
## Common Integration Patterns
### With Xray/V2Ray outbound
```json
{
"outbounds": [
{
"tag": "warp",
"protocol": "socks",
"settings": {
"servers": [
{
"address": "127.0.0.1",
"port": 1080,
"users": [
{ "user": "admin", "pass": "yourpass" }
]
}
]
}
}
]
}
```
### With Telegram (via proxychains)
```bash
# /etc/proxychains4.conf
[ProxyList]
socks5 127.0.0.1 1080
```
```bash
proxychains4 telegram-desktop
```
## Monitoring & Debugging
```bash
# Check container resource usage
docker stats microwarp
# Expected output:
# CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM %
# 2fa58f84c517 microwarp 0.25% 800KiB / 967.4MiB 0.08%
# View logs (first-run registration)
docker logs microwarp
# Inspect WireGuard interface inside container
docker exec microwarp wg show
# Check if SOCKS5 port is listening
docker exec microwarp ss -tlnp | grep 1080
# Test from inside container
docker exec microwarp wget -qO- --timeout=10 \
-e "use_proxy=yes" \
-e "https_proxy=socks5://127.0.0.1:1080" \
https://cloudflare.com/cdn-cgi/trace
```
## Troubleshooting
### Container fails to start — missing kernel module
```
Error: WireGuard kernel module not found
```
**Fix**: Ensure host kernel has WireGuard support (Linux 5.6+ has it built-in):
```bash
# Check host kernel
uname -r
# Should be 5.6+
# Verify wireguard module
modprobe wireguard && echo "OK"
```
Add `SYS_MODULE` capability and the sysctl:
```yaml
cap_add:
- NET_ADMIN
- SYS_MODULE
sysctls:
- net.ipv4.conf.all.src_valid_mark=1
```
### Registration fails / cannot connect to Cloudflare
**Fix**: Inject a known-good WARP endpoint:
```yaml
environment:
- ENDPOINT_IP=162.159.193.10:2408
```
Popular clean endpoints:
- `162.159.193.10:2408`
- `162.159.195.1:2408`
- `188.114.96.1:2408`
### SOCKS5 returns 503 intermittently
This is the WireGuard UDP handshake cold-start issue. **Fix**: Use `socks5://` not `socks5h://` in your client. The difference:
- `socks5://` — client resolves DNS, sends IP to proxy ✅
- `socks5h://` — proxy resolves DNS, hits WireGuard during coldRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.