FAQ

Relationship between Acceleration Configuration and Acceleration Line

1. Bandwidth Sharing: An acceleration line can be bound by multiple acceleration configurations, which 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 source site server?

These addresses are the IPs of the forwarding nodes of the acceleration cluster, which serve two purposes:

1. Transmit the traffic of your business data (the real IP of the visitor can be obtained through the toa module).
2. Conduct regular health checks on the source site server.

The health check of the origin server detects the availability of the origin server based on the principle of the TCP three-way handshake, and it is a short connection. Health checks for UDP ports are not supported for now.

Note: The security policies of the cloud service providers or IDCs related to the origin server may be sensitive to a large number of TCP short connections within a short period of time. For example, security products like Anqishi and Cloud Shield from other vendors may mistakenly block such IPs without your knowledge. For security reasons, it is recommended that after obtaining the list of outbound EIPs on the details page of the acceleration line, you add them to the whitelist of Cloud Shield in advance (including the trust list of CDN vendors from other vendors and the whitelist of WAF products).

How to obtain the real IP of the visitor?

Transmit your business data traffic (you can obtain the real IP of visitors through the toa module).
Due to passing through the acceleration line, a NAT conversion occurs, and the source client IP seen in the business logs becomes the outbound IP of PathX. If you need to obtain the real client IP, you can install the kernel toa module custom-developed by UCloud Global on the origin server, enabling the application to obtain the real source client IP without having to modify the 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 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. Use the yum command to search for kernel-devel and kernel-headers packages corresponding to the current kernel version. If they are found, install the corresponding versions (using the command 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 installation packages corresponding to the minor version of the kernel. Besides searching through search engines or websites like rpmfind, for historical versions of the CentOS system, you can check the x86_64/os/packages directory of the corresponding CentOS version on https://vault.centos.org/ .

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 out the real client IP, and finally complete the replacement through the kernel hook function. The socket library called by the service program can obtain the real client IP through the getpeername method. PathX does not support IPv6 acceleration. If the origin server service listens on both IPv4 and IPv6 addresses, such as the default listening method of a Golang service, the toa module also supports obtaining the client IP.

If the TCP connection is truncated during the forwarding process of the entire link, resulting in two separate TCP connections. For example, if a layer-7 load balancer or TCP request proxy mode is used before the RS, you will still fail to obtain the real client IP even after successfully installing toa:

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 (obtain client IP from http header)

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

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

Please check on the PathX resource details page, which can be used as a reference when setting up the whitelist on the origin server. These IPs may change in case of a DDoS attack or when the data center network is decommissioned. The IPs resolved from the accelerated domain name are the access point IPs closer to the client side, and they may also change under the circumstances of a DDoS attack or data center network decommissioning.

Can servers that are not UCloud Global servers use PathX?

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

Is website filing required?

1. If the selected acceleration region is in mainland China, after the business domain name is CName-recorded to the accelerated domain name, relevant filings need to be completed with the Ministry of Industry and Information Technology of the People’s Republic of China (there is a filing application entrance in the console).

2. If the selected acceleration region is outside mainland China, no filing is required regardless of where the client accesses from.

3. When using PathX as an accelerator for domestic CDN to return to an overseas server, the return-to-source http(s) request will pass through the PathX domestic data center nodes. The filing system will check whether the domain name saved in the host field of the http header has been filed at the data center POP point. Although the CName is not resolved to the accelerated domain name at this time, filing still needs to be applied for.

Is there any difference between PathX and CDN acceleration?

CDN accelerates access by caching resources at edge nodes. The cached objects are static media resources. The entire link is on the public network, and the cross-border backhaul routes are not very stable. Leading foreign CDN vendors have deeply optimized the backhaul network. However, due to policy impacts, the number of nodes in some regions is limited, and other products are needed for assistance.{channelName}}

PathX optimizes the cross-border (intercontinental) network quality from the client to the origin server. Relying on UCloud’s network scheduling capabilities, it controls packet loss and latency. It does not support application data caching, and each request will access the origin server to obtain resource data. It is suitable for scenarios such as payments, logins, chatting, and long connections. It also supports application layer protocols such as WebSocket and HTTP. It terminates the TCP connection in advance on the client-side, and the end-to-end long-connection optimization can significantly improve the 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 offloading SSL nearby and using the HTTP protocol to return to the origin, you can use the HTTPS-HTTP mode in the Layer 7 port forwarding of PathX.

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 accelerations from North China, East China, and South China to Hong Kong as an example. After creating an acceleration, users in North China, East China, and South China access the same accelerated domain name, but the resolved IPs are different. These IPs respectively correspond to the entry points of PathX in the three regions. That is to say, when users from different regions access the PathX accelerated domain name, the IP of the acceleration entry point closest to the user will be resolved.

After the resources have been in use for a period of time, the accelerated domain name + port of PathX or GlobalSSH suddenly cannot be accessed normally, while the origin site + port can be accessed normally.

When using curl for testing, it will generally report “curl: (56) Failure when receiving data from the peer”. When using telnet for testing, after the connection is successfully prompted, “Reset By Remote Peer” will be received immediately. Important! Important! Important! When using nc for testing, it will prompt that the connection is successfully established.

1. Check whether there are security policy settings on the origin server, such as Alibaba Cloud’s Anqishi (Cloud Shield will automatically block it without any configuration by the user. It is necessary to enable the whitelist IP protection and trust CDN vendors). If there are security measures like fail2ban, etc., you can obtain the exit IPs of PathX or GlobalSSH from the resource details page of the console 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 the recycling of TCP connections (it is effective when conducting stress tests as a client or sending a large number of requests outward). Since tcp_tw_recycle was designed quite early and didn’t take into account the fact that NAT technology has now become prevalent in the public network, it will lead to the failure of some connections for users going through NAT (such as in Internet cafes, using 4G networks, or WIFI). Currently, this parameter is basically obsolete. To increase the speed of TCP recycling, it can also be achieved by reducing the tcp waiting timeout period.

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, and the client needs to reconnect.

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 details page of the acceleration line and the acceleration configuration page, a drop - down list is available to select different acceleration regions, which facilitates the location of the entry points with a relatively high bandwidth occupancy.

PathX’s traffic throttling measures

PathX throttles traffic based on the purchased bandwidth. When the real-time bandwidth (the maximum value between the outgoing bandwidth and the incoming bandwidth) exceeds the purchased bandwidth, traffic throttling will be triggered. Traffic throttling may lead to phenomena such as an increased packet loss rate and connection interruptions. The traffic throttling will be automatically lifted when the real-time bandwidth is lower than the purchased bandwidth. Please configure bandwidth utilization rate alerts on the line details page. The PathX bandwidth monitoring data needs to be dynamically collected and calculated, and there is a 1-2 minute lag in the computer rooms around the world. As a result, the actual bandwidth may significantly exceed the purchased bandwidth in a short period. When the bandwidth reporting is completed and the traffic throttling instruction is issued, it may cause a serious packet loss situation.

Explanation of capacity limitations related to acceleration configuration

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). For Layer 4 forwarding, protocols such as http2, quic, ipsec-vpn, rtmp, rtc, etc. can be extended. ssl-vpn requires non-standard support, and ftp access is not supported;

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. High-performance clusters are available for selection. Please feel free to contact us if you have such a need.

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

1. If multiple IPs are resolved from the filled origin domain name, a health check will be conducted once every 30 seconds for all combinations of origin IPs + ports (ports of the UDP protocol are not included for the time being). The origin nodes that fail the health check will be removed;

2. New connection requests from clients will be distributed among multiple origin IP nodes in a round-robin manner.