Help & Support
Welcome to the Safewoo Help Center. Here you can find answers to common questions. If you cannot find what you are looking for, feel free to contact us.
#Is Safewoo really a no-logs VPN?
#How is traffic calculated?
- All requests sent from you to the proxy node
- All data sent from the proxy node back to you
- All data forwarded by the proxy node to the target server on your behalf
- All responses received by the proxy node from the target server for you
#What time does the traffic reset?
If you subscribe on February 29th, your data usage will be reset on the 28th (or 29th in leap years), whichever is the last day of the month.
#What is the traffic routing rule?
Safewoo evaluates a set of rules in order and uses the first matching rule to decide whether traffic goes through the VPN or connects directly. Below is a plain-language explanation of each rule type we use.
- Ports 6881–6889: these ports are commonly used by torrent/file-sharing clients — connections using these ports are usually allowed to connect directly for better speed.
- Port 25: standard outgoing email (SMTP) — routed directly to improve compatibility with mail servers.
- Port 465: secure SMTP (legacy SSL) — routed directly for mail compatibility.
- Port 107: a specific legacy/service port included for compatibility and routed directly.
- Port 194: included as a legacy/service port routed directly when needed.
- Port 587: modern email submission port — routed directly to allow mail clients to upload messages reliably.
- Port 2525: an alternative SMTP submission port used by some providers — routed directly for compatibility.
- Port 6969: a common BitTorrent tracker port — routed directly to avoid proxy abuse.
- Port 51413: the default peer port for Transmission (used by many clients) — routed directly for compatibility.
- Port 992: a secure legacy service port included for compatibility and routed directly.
- Local network (LAN): any traffic to devices on your local network is kept direct so your local devices remain reachable.
- China IPs: IPs geolocated to China are routed directly (so China-local services use a direct path).
- Private group: a named group for private/internal destinations that should always use a direct connection.
- iCloud / Apple groups: Apple-related services (icloud, apple) are routed directly when needed for reliability and compatibility with Apple services.
- Direct group: a named collection of destinations that are always connected directly for speed or compatibility.
- LAN CIDR / CN CIDR groups: specific IP-range groups for local or China networks that should be direct.
- Proxy group: a named group of destinations that should always be routed through the proxy (for privacy or to access content).
- GFW group: destinations known to be blocked or restricted from your location are routed through the proxy so they remain accessible.
- Telegram CIDR group: Telegram-related IP ranges are routed through the proxy when needed.
- Fallback: any traffic that does not match earlier rules is sent through the VPN/proxy by default.
Note: to prevent abuse — both spam via email and misuse of the proxy for peer-to-peer traffic — we route common outgoing mail ports (for example 25, 465, 587, 2525) and common P2P/torrent ports (for example 6881–6889, 6969, 51413) directly rather than through the proxy.
If you need a specific change (for example to force a particular app or site to use direct or VPN), contact our support team and we can help with a custom route.
#Proxy abuse / port handling
We monitor and limit common proxy abuses to protect our network and other users. Below is a short summary of what we treat as high risk and how we handle it.
- Email relays (ports 25, 465, 587, 2525): outbound mail submission through the proxy is routed directly or rate limited to prevent spam relay.
- P2P / torrent ports (6881–6889, 6969, 51413): these are routed directly to avoid high-volume abuse and tracker misuse.
- Open-proxy service ports: we treat ports commonly used by proxy services (for example 3128, 8080, 8000, 8888, 8118, 1080) with stricter controls and do not allow unauthenticated proxy chaining.
Mitigations we apply include rate limits, requiring authenticated relays, blocking or forcing direct on risky ports, and alerting on unusual outbound patterns. If you need a specific exception for an application, contact support and we can evaluate it. These protections are applied automatically; you do not need to reset routing rules yourself.
Still Need Help?
If you have any other questions, please do not hesitate to reach out to our support team.
Contact Support