FAQ

Relationship between Acceleration Configuration and Acceleration Line

1. Bandwidth Sharing Feature: An acceleration line can be bound by multiple acceleration configurations, and these configurations share the bandwidth of the acceleration line.
2. An acceleration configuration can be bound to multiple acceleration lines.
3. Deleting an acceleration configuration does not affect the acceleration line; the acceleration line still exists.
4. If an acceleration line is bound with an acceleration configuration, it cannot be deleted. If there are no acceleration configurations bound to an acceleration line, it can be deleted.

Why do I see a large number of fixed IP addresses accessing the origin server?

These addresses are the acceleration cluster forwarding node IPs, serving two purposes:

1. Transmitting your business data traffic (you can obtain the real IP of visitors via the toa module).
2. Performing health checks on the origin server regularly.
   Health checks on the origin server are conducted using the TCP three-way handshake principle to probe the availability of the origin server. This is a short connection. For UDP ports, health checks are currently not supported.

Note: The security policies of cloud service providers or IDC related to the origin server may be sensitive to a large number of TCP short connections in a short period. For example, competing products like Anjian or Cloud Shield might mistakenly block these IPs without your awareness. For security reasons, it is recommended to obtain the outbound EIP list on the acceleration line detail page and add it to the Cloud Shield whitelist in advance (including the trusted list of competing CDN vendors and the WAF product whitelist).

How to obtain the real IP of the visitor?

Your business data traffic is transmitted (you can obtain the real IP of visitors through the toa module).
Due to NAT conversion occurring via the acceleration line, the source client IP seen in the business log becomes the PathX outbound IP. If you need to get the real client IP, you can install the UCloud Global custom-developed kernel toa module on the origin server, allowing the application to obtain the real source client IP without modifying any code.

Linux System

1. Check the current kernel version number and confirm whether “kernel-devel, kernel-headers” dependencies are installed and whether their version numbers match the kernel version (‘uname -r && rpm -qa | egrep ‘kernel-devel|kernel-headers’):
   If they match, skip to step 2 and proceed with the compilation and installation of the toa module.
   If they don’t match, as shown below:

If dependencies are not installed, as shown below:

2. Search using yum to see if there are kernel-devel and kernel-headers corresponding to the current kernel version.
   If available, install the corresponding version (yum install pkgname-version.x86_64).
   If not, as shown below:

Open the website http://rpm.pbone.net , click the SEARCH tab on the left, enter the package name and version number (e.g., kernel-devel-3.10.0-693.11.6.el7.x86_64), select the corresponding system release version (here CentOS7), and click search.

3. Download the kernel-devel and kernel-headers rpm packages corresponding to the minor kernel version number. Besides searching engines or using rpmfind to locate them, you can also check the x86_64/os/packages directory of the corresponding centos version at https://vault.centos.org/  for historical versions of the centos system.

4. Download the TOA module.

git clone https://github.com/ucloud/toa.git

5. Compile and load the TOA module.

yum install -y gcc
cd toa
make
mv toa.ko /lib/modules/`uname -r`/kernel/net/netfilter/ipvs/toa.ko
insmod /lib/modules/`uname -r`/kernel/net/netfilter/ipvs/toa.ko

Verification of TOA module installation is as follows (lsmod | grep toa):

6. Add the module to load automatically at startup.

echo "insmod /lib/modules/`uname -r`/kernel/net/netfilter/ipvs/toa.ko" >> /etc/rc.local

In an nginx environment, view the real visitor addresses directly in nginx logs. Log path: /var/log/nginx/access.log

In an apache environment, view the real visitor addresses directly in apache logs.

Log path: /etc/httpd/logs/access_log

• For other web configuration environments, follow the same method to check the relevant web log files.

Still unable to view the real client IP after installing TOA

The principle of TOA is to extract the option field from the TCP packet, parse the real client IP, and finally replace it through kernel hook functions. The socket library used by service programs can obtain the real client IP through the getpeername method. PathX does not support IPv6 acceleration. If the origin server service is listening to both IPv4 and IPv6 addresses, as is the default in golang services, the TOA module also supports obtaining the client IP.

If in the whole forwarding process of the link there is a TCP connection truncation, causing the link to be split into two TCP connections, such as using a 7-layer load balancing or TCP request proxy mode in front of RS, even with TOA installed, you will not be able to get the real client IP:

1. client -------> pathx layer-4 forwarding --------- TCP packet (option field contains: client IP) --------> 7-layer load balancing or TCP request proxy load balancing ----------TCP packet (option field no longer contains client IP) --------> origin RS (TOA installed but unable to obtain client IP)

2. client -------> pathx layer-4 forwarding --------- TCP packet (option field contains: client IP) --------> origin RS (TOA installed and able to obtain client IP)

3. client--------> pathx layer-4 forwarding --------- TCP packet (option field contains: client IP) --------> layer-4 load balancing (ulb4 with packet forwarding enabled or AWS NLB preserving the source IP) ----------TCP packet (option field contains client IP) --------> origin RS (TOA installed and able to obtain client IP)

If using the http protocol scenario, layer-7 forwarding allows obtaining the real client IP without installing the TOA module:

4. client--------> pathx layer-7 forwarding ------X-Forwarded-For---------> various LBs --------> origin RS (obtained from http header)

5. client--------> pathx layer-7 forwarding ------X-Forwarded-For---------> origin RS (obtained from http header)

How to view PathX’s source IP (the forwarding node IP near the origin)?

Please check the PathX resource detail page for reference when setting a whitelist on the origin server. These IPs may change in case of DDoS attacks or data center network cuts. The IP resolved from the accelerated domain name is the access point IP near the client side, which may change in case of DDoS attacks or data center network cuts.

Can servers that are not UCloud Global servers use PathX?

Yes, as long as the servers are reachable via public internet routing.

Does the website need to be registered?

1. If the selected acceleration region is in mainland China, after the business domain name CNames to the acceleration domain name, you need to complete relevant registration with the Ministry of Industry and Information Technology of the People’s Republic of China (the console provides an entry for registration application).

2. If the selected acceleration region is outside mainland China, registration is not required, regardless of the client’s access location.

3. When using PathX as an accelerator for CDN backhaul from overseas servers to domestic servers in China, the backhaul http(s) request will pass through PathX domestic data center nodes. The registration system will check the host field saved in the http header for registration at the data center pop point. Although at this time, cname does not resolve to an accelerated domain name, registration is still required.

What’s the difference between PathX and CDN acceleration?

CDN accelerates access by caching resources at the edge nodes, typically for static media resources. The whole link is on the public internet, and the cross-country origin-back line is not very stable. Leading CDN vendors have deeply optimized the backhaul network, but due to political factors, the number of nodes in certain regions is limited and may require additional products for assistance.

PathX optimizes cross-country (continental) network quality from the client to the origin site. It leverages UCloud Global network scheduling capabilities to control packet loss and latency, does not support application data caching, and each request accesses the origin site for resource data. It’s suitable for payment, login, chat, long connections, and other scenarios, supporting protocols such as websocket, http, etc. TCP connections can be terminated early on the client-side, optimizing end-to-end long connections, which can significantly enhance link speed.

Can it be used in HTTP(s) websites or API scenarios?

1. Yes, PathX supports TCP passthrough to the origin. Configure TCP ports 80 or 443 in the console, and the certificate is still deployed on your business server without additional settings needed.

2. If your business scenario requires SSL Offloading nearby, and uses HTTP protocol as a backhaul, you can use the PathX 7-layer port forwarding in HTTPS-HTTP mode.

3. If you are using HTTP(s) requests and the origin server is inconvenient to install the TOA module but still want to obtain the real client IP, you can use PathX HTTPS-HTTPS or HTTP-HTTP forwarding modes.

What is multi-region access?

Take the accelerated connection from North China, East China, and South China to Hong Kong as an example. After the acceleration is created, users in North China, East China, and South China access the same accelerated domain name, but the IPs resolved are different. These IPs correspond to the pathx entry points in the three regions. That is, users in different regions accessing the pathx accelerated domain name will resolve to the accelerated entry IP closest to the user.

After using the resources for some time, the PathX or GlobalSSH accelerated domain name + port suddenly becomes inaccessible, while the origin site + port is accessible.

When using curl to test, you generally get “curl: (56) Failure when receiving data from the peer.”
When using telnet to test, it indicates a successful connection, but immediately receives “Reset By Remote Peer.”
Importantly! When using nc to test, it indicates that the connection was successfully established.

1. Check if the origin site has security policies set, such as Alibaba Cloud’s Security Center (Cloud Shield may automatically block without user configuration; CDN whitelist protection needs to be enabled) or fail2ban, etc. If there are, you can obtain the PathX or GlobalSSH outbound IP from the console resource details page and add them to the whitelist.

2. If the above does not solve your problem, first submit a ticket to inquire with your origin server provider about whether there are security policies automatically blocking unknown source IPs.

3. Check system parameter settings

   net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_tw_reuse = 1

Enabling tcp_tw_resuse is sufficient for TCP connection recycling (effective when acting as a client under pressure testing or sending a large number of requests externally), while tcp_tw_recycle’s early design did not consider the widespread use of NAT technology on the internet today, leading to failed connections for users partaking through NAT (such as internet cafes, 4G, WIFI). Nowadays, this parameter is largely deprecated. The speed of tcp recycling can also be improved by reducing the tcp wait timeout time.

Can the origin site be modified?

Since July 2020, PathX acceleration origin sites support modification. You can change to a new origin IP or domain on the acceleration configuration detail page without changing the original acceleration domain names and ports. Note that after changing the origin site, a temporary service interruption might occur requiring client reconnection.

Can PathX resources be recovered after cancellation due to non-payment?

They can’t be recovered. At this point, resources in our billing and resource system are marked for deletion, and you’ll need to create new resources.

Can PathX be configured with bandwidth alerts?

You can configure in “Alert Template” on the acceleration line details page, supporting alerts for absolute bandwidth values and bandwidth usage rate. On the acceleration line detail page and acceleration configuration page, dropdown lists can select different acceleration regions to help locate bandwidth-heavy entry points.

PathX’s Traffic Limiting Measures

PathX limits according to purchased bandwidth. When real-time bandwidth (the maximum between outbound and inbound bandwidth) exceeds the purchased bandwidth, throttling is triggered. Throttling may lead to increased packet loss rate, connection interruption, etc. When real-time bandwidth is below the purchase bandwidth, throttling is canceled automatically. Please configure the bandwidth usage rate alert in the line details page. PathX bandwidth monitoring data requires dynamic collection and calculation, distributed across global datacenters, causing a 1-2 minute delay, resulting in short-time actual bandwidth greatly overrunning the purchased bandwidth. Then, issuing throttling instruction after bandwidth reporting can lead to severe packet loss.

Limitations on Acceleration Configuration Related Capabilities

1. Number of acceleration regions: Unlimited;

2. Number of ports: 50;

3. Support scenarios for 4-layer and 7-layer protocols: http(s), websocket(s), 4-layer forwarding can expand http2, quic, ipsec-vpn, rtmp, rtc, etc., protocols. SSL-vpn requires non-standard support, and ftp access is unsupported.

4. 4-layer port forwarding: Concurrent connection limit on common clusters is 10,000;

5. 7-layer port forwarding: On common clusters, single source IP (client) concurrent limits are 100, with maximum concurrent connections of 4,000; https requests will be slightly less. Option to choose high-performance clusters, feel free to contact us if you need details.

How to handle load balancing for origin domain names and multiple origin IPs?

1. If the filled-in origin domain name resolves to multiple IPs, every 30 seconds, a health check will be conducted for all origin IP + port combinations (excluding UDP protocol ports for now) to eliminate failed health check nodes;

2. Connection requests added by clients will be distributed among multiple origin IP nodes in a round-robin manner.