Linkage Methods And Deployment Cases Of Hong Kong’s Native Ip Airport And Cloud Acceleration Products

1. overview and prerequisite preparation

description of the goal: connect hong kong’s native ip “airport” node (ssh/vpn/proxy service host) to cloud acceleration (cdn/anycast/waf) to improve accessibility and protection. prerequisites: you have purchased a hong kong vps and been assigned a native public ip, you have opened a cloud acceleration service account (such as a cdn/anycast/waf vendor), and you can modify the domain name dns.

2. plan topology and port strategy

small segmentation: determine the return-to-origin port (such as 443, 80 or custom port), protocol (tcp/udp), and whether a transparent proxy or reverse proxy is required. it is recommended to open only necessary ports and enable tls when going back to the origin. develop bandwidth and concurrency estimates and evaluate whether multi-node anycast is needed.

3. hong kong vps basic environment construction

small segments: log in to the vps (example: ssh root@hk_ip), update the system (debian/ubuntu: apt update && apt upgrade), and install necessary software (nginx, iptables, certbot, tcpdump). bind the business service to the local back-to-source port (for example, local nginx listens to 127.0.0.1:8443 or 0.0.0.0:443).

4. local firewall and nat configuration

small segment: strictly restrict inbound. example iptables rules: iptables -f; iptables -a input -m conntrack --ctstate established,related -j accept; iptables -a input -p tcp --dport 22 -j accept; iptables -a input -p tcp --dport 443 -j accept; iptables -a input -j drop. if the service runs on a non-standard port, add corresponding rules. if port mapping is required: iptables -t nat -a prerouting -p tcp --dport 443 -j redirect --to-port 8443.

5. domain name and dns settings (access to cloud acceleration)

small segment: add domain name records in the dns management console. if you use cdn/anycast, you usually cname the domain name to the acceleration domain name provided by the manufacturer; if the manufacturer requires an a record, point the a record to the acceleration node ip or reserve the native ip for back-to-origin. example: origin.my-domain.com points to the hong kong vps native ip (back-to-origin record, usually not disclosed and the proxy is enabled in the cdn panel).

6. cloud acceleration panel back-to-source configuration

small segment: log in to the cloud acceleration console, create a new site, and fill in the back-to-origin domain name or back-to-origin ip (fill in origin.my-domain.com or hk_ip from the previous step). set the back-to-origin protocol to https/enable sni, and set the back-to-origin port (such as 8443 or 443). configure the health check path (for example, /healthz) and frequency to ensure that the cloud can detect that the return to origin is normal.

7. tls/certificate and back-to-origin certificate management

small segment: enable certificates (let's encrypt or your own certificate) in the cloud for accelerated domain names, and enable self-signed or trusted certificates back to the origin. if it is a self-signed certificate, select "allow self-signed/ignore back-to-source certificate verification" in the cloud acceleration panel or upload a ca. it is recommended to use sni and ensure that the certificate domain name matches the back-to-origin domain name.

8. anycast/bgp and multi-node deployment (optional)

small segmentation: if cross-network optimization or disaster recovery is required, purchase multiple native ip nodes in hong kong or nearby areas and set up multiple origins in cloud acceleration. when using anycast, the cloud will route user requests to the nearest node; ensure that all back-to-origin nodes are configured consistently, and synchronize user status (session or database) on the backend.

9. back-to-origin current limiting, waf and security strategy

small segmentation: configure waf rule sets, crawler management and back-to-origin traffic limiting (qps limitation) in the cloud. set connection limits on the vps side (eg nginx limit_conn & limit_req). enable cc protection, geo-blocking and other strategies to reduce the pressure of returning to the source.

10. testing and troubleshooting

small segment: test steps: 1) use nslookup/dig to confirm that the domain name is resolved to cloud acceleration; 2) curl -v https://your-domain to check the certificate and return header; 3) traceroute/mtr to check the path; 4) check the health check log in the cloud panel; 5) if the return source is unreachable, check the vps iptables, service monitoring and cloud logs (return to source ip rejection/timeout).

11. deployment case: single node hong kong native ip + cdn back-to-origin example

small segment: example steps: 1) deploy nginx on the vps, listen to 8443 and configure the certificate; 2) create origin.example.com -> hk_ip in dns; 3) add a new site in the cdn console, fill in origin.example.com and return port 8443; 4) enable https in the cdn and bind it to the cdn certificate; 5) after completion, test and observe the access delay and concurrency performance.

12. frequently asked questions and optimization suggestions

small segments: it is recommended to enable gzip/caching headers to reduce the load on the origin, use long connection keep-alive, monitor bandwidth peaks and reserve elastic expansion. when encountering a udp proxy, you need to confirm whether the cloud acceleration supports udp back-to-source or uses a tunnel/dedicated line solution.

13. question: when using hong kong’s native ip as a return source, how to avoid leaking the real ip?

answer: set the back-to-origin domain name in dns to non-public (not externally resolved), and cname the external domain name to the cdn; the vps firewall only allows the ip segment of the cloud acceleration node to access the back-to-source domain (the cloud manufacturer will announce the acceleration export ip segment), and rejects other sources to prevent direct connections that bypass the acceleration.

14. question: should i choose self-signed or public chain certificate for the back-to-origin certificate?

answer: in the production environment, it is recommended to use a public chain certificate for back-to-origin or allow the cloud to allow self-signing and enable the "verify back-to-origin certificate" policy in the cloud panel. if self-signing is used, it must be explicitly allowed in the cloud and ensure that the sni domain name matches to avoid tls handshake failure.

15. question: how to monitor and quickly locate line/node problems?

answer: combine the monitoring of the cloud acceleration platform (qps, bandwidth, health check) with the tcpdump, nginx access/error log, and mtr/traceroute on the vps side. if necessary, deploy detection points in multiple regions for comparison. quickly locate the problem caused by cloud routing, return-to-origin failure, or local firewall.