Your expectations might be a little off here. It will not automatically sum the speed of any download.
A download is one connection to one server, and it will be no faster. To get extra speed you need a webrowser plugin/downloader program that splits the request into several pieces (requests), and then it makes concurrent part requests and you can get the benefit of the sum total of two WAN’s… maybe.
Most times when the underlying connection or session is https, it cannot be split across multiple WAN’s, because to the server this looks to be an error. Netflix and other paid streaming suffer this.
Check the outbound policy default rules. You need to have one that makes all port 443 traffic, a persistent to a WAN rule. Then the default rule for all else, needs to be set for your preference - the 50M fiber WAN probably.
Yet another un-handled issue is DNS. Each WAN has different answers to the same questions for the major sites, because of internal CDN’s. But the default Peplink has no inbuilt rules to match up the proper WAN path to the DNS answer. i.e. DNS on WAN A says ip 220.127.116.11, which is only available to its own internal customers from within its net. But the Peplink tries to route request through WAN B, going to the resource via a public route to A, without success. The solution is to add a table of routes that are specific to each WAN…