Blocked at the door
The check happens while the connection is being opened, not in hindsight. If the destination matches the ruleset the connection is refused on the spot, and no traffic ever leaves your device.
Compliance
Run clean. Stay traceable.
What is my connection actually used for, can it get me into trouble, and how do you police it? This page answers all three. Node owners share exit bandwidth that carries ordinary network requests from platform customers. We block high-risk destinations by domain at the gateway, restrict which connections may enter the dispatch pool, require verified identity on every account, and write every policy and money operation to an audit log.
0
Outbound blocklist rules live today
0
Documents you must accept on first launch
0s
Worst-case convergence for policy changes
SHA256
Integrity digest computed per legal document
These are the mechanisms in force today; the rule count keeps growing as governance requires. Nothing on this page is a promise of earnings.
Outbound control
Blocklist, live on write
We maintain a single outbound domain ruleset. Once written centrally it is broadcast over a publish/subscribe channel to every gateway, and each gateway matches the destination domain at the moment a connection is opened — a match is refused outright. Adding a rule needs no restart and no device reconnect: it takes effect the instant the broadcast lands. The first 101 rules are already live.
Broadcast, not restarted
The ruleset lives centrally and every change is pushed to all gateway processes over pub/sub. One new rule is enforced immediately, with no service restart and no waiting for devices to reconnect.
No retry on another device
A match returns an explicit TARGET_DENIED. The client is not re-dispatched to a different device to try again, so your phone is never used to hammer at a destination that has already been refused.
Validated on both sides
Rule syntax is validated once in the admin console and again on the server. Malformed rules cannot be saved, so a typo can never take legitimate domains down with it.
To be precise: this is real-time domain matching at the gateway, not access logging. We do not record destination URLs or payload content, and the block itself leaves no browsing record. Equally, it is not a "zero-log" system — for billing we meter traffic in MB and write it to settlement windows, and we record whether a device is online and running.
Rule syntax
Three forms cover different scopes, and the console validates against the same grammar before saving.
| Form | Written as | What it matches |
|---|---|---|
| Exact | example.com | That domain only; subdomains are unaffected |
| Suffix | +.example.com | The domain plus every subdomain at any depth |
| Single wildcard | *.example.com | * matches exactly one label: a.example.com matches, a.b.example.com does not |
Informed consent
Consent gate on launch
The first time the app opens you hit a consent gate: decline and nothing works. And it is not one catch-all agreement — three separate documents are presented on their own terms.
Three documents to accept
User Agreement
Account rules, what you may and may not do, how violations are handled, and how to leave at any time.
Privacy Policy
What the app collects, why, where it is stored, and the rights you can exercise over it.
Network Exit Authorisation
The document specific to node owners. It states plainly that your connection will carry compliant network requests on behalf of platform customers, and takes your authorisation for exactly that. It is never folded into the other two — separate document, separate confirmation.
How it is enforced
Per-document integrity check
The server computes a content_sha256 for each document; the client recomputes and compares it on fetch, and refuses to display anything that does not match.
Versions are never reused
One publish equals one globally unique version covering the complete document set. A version number is never reused, so it stays possible to establish exactly which text a given device accepted.
Live the moment it ships
After a new version is published, devices that have not accepted it receive CONSENT_REQUIRED on their next API call and must walk the consent flow again before they can keep running.
Do not confuse the two sets: these three in-app documents are for node owners, while the terms and privacy policy on the main site are for platform customers. They are published and maintained separately.
Identity
Verified people, not phones
Verification attaches to the phone-number account, not to any single device. One account can carry several devices and you verify once. Verification must be complete before you can withdraw.
Why we insist on it
Earnings are paid out as real Alipay transfers, so the payee has to be verifiable — and if something goes wrong, responsibility has to trace back to a real person.
The name has to match
Withdrawals require an Alipay account plus the payee's legal name. Alipay verifies the name itself and rejects the transfer outright on a mismatch, so money cannot land in someone else's account.
Reviewers see masked data
Payout accounts and names are always masked in the admin console (138****1001, Chen*). Reviewers approve on that basis and never see the full details.
You can run a device without binding a phone number, but the dashboard will then only count that handset and you cannot withdraw. Bind a number and verify to pool earnings across every device on the account. Any personal income tax or other levies arising from a payout are declared and borne by the payee, as required by law.
Eligibility
Who gets into the pool
Not every connection qualifies. Carrier admission is on by default: we resolve which network an exit IP belongs to, and only listed broadband exits take part in dispatch.
Admitted to the pool
- China Telecom
- China Unicom
- China Mobile
- China Broadnet (CBN)
- CERNET (education network)
Never admitted
- Data-centre, IDC and public-cloud IPs
- Overseas ISP exits
- Broadband whose owner cannot be resolved
- Emulators, cloud phones and data-centre networks (explicitly prohibited)
A device outside the pool still shows as online, but proxy requests never reach it: it is flagged isp_error and earns nothing. The only fix is to move it onto a listed home broadband line or mobile data.
Three device states
Every registered device sits in exactly one of these states, and every transition is logged.
| State | Meaning | Effect on dispatch |
|---|---|---|
active | Connected and past carrier admission | Takes traffic; settled on what it actually carries |
revoked | Unbound by the owner or reclaimed | Leaves the pool and receives nothing further |
blocked | Banned for a violation, by device or by exit IP | Dropped from the gateway as soon as the ban is broadcast |
Admission-policy edits are not force-broadcast: gateways re-read them on their heartbeat, so worst case they converge in about 15 seconds. Bans are broadcast immediately and do not wait for a heartbeat.
Audit trail
Everything that matters is logged
Every back-office action touching permissions, policy or money writes an audit record with the operator, the timestamp and what changed. Reconstructing who changed what, and when, never depends on anyone's memory.
- Device state changes, plus bans and unbans applied by device or by exit IP
- Additions to and removals from the outbound blocklist
- Toggling carrier admission and editing the carrier list
- Publishing in-app legal documents and switching versions
- Withdrawal decisions (approved or rejected) and payout outcomes
Withdrawals add idempotency on top: one withdrawal always maps to one merchant order number, and platform and payment-channel references resolve to each other in both directions. When a payout result is uncertain the request stays in "paying" until the payment channel gives an authoritative answer — we never guess, which is what keeps a payout from going out twice. Points from rejected or failed payouts are returned per request.
Data handling
Stored in China. Collected sparingly.
Data is held on servers inside mainland China. The list below is deliberately specific: what is named is collected, and what is not named is not.
What we collect
- Device identifier and runtime state: online or not, running or stopped, and the result of each readiness check
- The exit IP and the carrier resolved from it, used for admission and for pooling devices behind one exit
- Traffic metered in MB, and the settlement window it belongs to
- Account data: phone number, identity-verification result, and the payout details needed to withdraw (masked in the console)
What we do not collect
- No destination URLs and no payload content from proxied requests
- No personal files on the device beyond what running and settling the node requires
This page covers only the data handling tied to node operation; the privacy policy remains the authoritative statement.
Operator and filing
A named operator you can check
The Node Program is operated by the entity below, and the ICP filing can be verified directly with the Ministry of Industry and Information Technology.
Operating entity
海南高峰鑫田商贸有限公司
ICP filing
琼ICP备2025057067号-1Official domain
www.gaofengxt.cn
Support email
support@gaofengxt.cnCustomer-facing legal documents
These apply to platform customers and site visitors. They are a separate set from the three in-app consent documents — do not read one as the other.
Compliance Q&A
The questions owners actually ask
Straight answers, each based on a mechanism that is live in production today.
- Could my connection be used for something illegal?
- The platform carries ordinary customer requests and blocks high-risk destinations by domain at the gateway. The first 101 rules are live, and a new rule takes effect the moment it is broadcast — no device reconnect needed. Customers sign terms of their own and answer for how they use the service. We will not claim abuse is never attempted; we will commit to this: every case we find becomes a rule, and that rule applies across every gateway at once.
- If traffic causes a problem, am I liable?
- A node owner supplies an exit; you neither choose nor see the content of individual requests. We manage misuse through verified identity, admission rules, the outbound blocklist and audit logs, and we reserve the right to act against offending accounts and devices. If you are ever asked about traffic from your exit IP, write to support@gaofengxt.cn and we will help investigate and supply the records needed.
- Can you see the traffic that passes through my device?
- No. The destinations and contents of the traffic relayed through your device are not recorded; the blocklist matches domains as a connection opens and keeps no record afterwards. To be straight with you, that is not the same as "zero logs": billing requires us to meter traffic in MB into settlement windows, and we record whether a device is online and running.
- Can minors take part?
- The programme involves identity verification and real payouts, so minors should only use it with a guardian's guidance and should not take part independently without consent. The payout account and verified identity should belong to an adult with full legal capacity.
- Why are emulators and cloud phones not allowed?
- Their exits almost always land on data-centre IPs, which admission rules exclude from the dispatch pool outright, and they do not represent a real home or mobile network. Installed on one, the app will show as online and simply never receive traffic or earn anything.
- Who do I contact when something goes wrong?
- Our support email support@gaofengxt.cn is the only official channel. Decisions on reviews, bans and withdrawals are all visible in the app, and each has a matching audit record we can check against if you need us to.
Could my connection be used for something illegal?
The platform carries ordinary customer requests and blocks high-risk destinations by domain at the gateway. The first 101 rules are live, and a new rule takes effect the moment it is broadcast — no device reconnect needed. Customers sign terms of their own and answer for how they use the service. We will not claim abuse is never attempted; we will commit to this: every case we find becomes a rule, and that rule applies across every gateway at once.
If traffic causes a problem, am I liable?
A node owner supplies an exit; you neither choose nor see the content of individual requests. We manage misuse through verified identity, admission rules, the outbound blocklist and audit logs, and we reserve the right to act against offending accounts and devices. If you are ever asked about traffic from your exit IP, write to support@gaofengxt.cn and we will help investigate and supply the records needed.
Can you see the traffic that passes through my device?
No. The destinations and contents of the traffic relayed through your device are not recorded; the blocklist matches domains as a connection opens and keeps no record afterwards. To be straight with you, that is not the same as "zero logs": billing requires us to meter traffic in MB into settlement windows, and we record whether a device is online and running.
Can minors take part?
The programme involves identity verification and real payouts, so minors should only use it with a guardian's guidance and should not take part independently without consent. The payout account and verified identity should belong to an adult with full legal capacity.
Why are emulators and cloud phones not allowed?
Their exits almost always land on data-centre IPs, which admission rules exclude from the dispatch pool outright, and they do not represent a real home or mobile network. Installed on one, the app will show as online and simply never receive traffic or earn anything.
Who do I contact when something goes wrong?
Our support email support@gaofengxt.cn is the only official channel. Decisions on reviews, bans and withdrawals are all visible in the app, and each has a matching audit record we can check against if you need us to.
Read the rules, then plug in
Compliance runs both ways: we publish the rules, you join on those terms. Next, check the device requirements on the download page or look up your case in the FAQ.